Hi,
I've ported pg_lesslog to PostgreSQL 9.0 and I'm testing it.
I'm not successful to produce the following WAL records.
XLOG_HEAP_INIT_PAGE
XLOG_BTREE_REUSE_PAGE
XLOG_GIST_PAGE_DELETE
XLOG_RELMAP_UPDATE
Any suggestions are welcome.
Thank you very much;
--
Koichi Suzuki
--
Sent via
itag...@postgresql.org (Takahiro Itagaki) wrote:
Fix dblink to treat connection names longer than NAMEDATALEN-2 (62 bytes).
Now long names are adjusted with truncate_identifier() and NOTICE messages
are raised if names are actually truncated.
Modified Files:
--
Folks;
It is an announcement that pg_lesslog 1.4.2 beta is now available for
PostgreSQL 9.0 beta2. You can download the latest file from
http://pgfoundry.org/projects/pglesslog/
This is only for PosrgreSLQ 9.0 beta 2. Please do not use this
against older version of PostgreSQL. For 8.3 and
I found contrib/dblink leaks a connection or a small amout of memory
when dblink_connect() ends with a duplicate connection name error.
We should disconnect the connection before raise any ERRORs.
Patch attached.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
2010/6/7 Greg Stark gsst...@mit.edu:
On Mon, Jun 7, 2010 at 7:33 PM, Peter Eisentraut pete...@gmx.net wrote:
I have developed a patch that partially implements the functional
dependency feature
Nice! :)
I like this idea too. It can simplify some queries and I believe - it
is very good
* Greg Smith:
Florian Weimer wrote:
It has been claimed before that YAML is a superset of JSON, so why
can't the YAML folks use the existing JSON output instead?
Because JSON just crosses the line where it feels like there's so much
markup that people expect a tool is necessary to read
On tis, 2010-06-08 at 09:59 +0900, Hitoshi Harada wrote:
Also, when a column is compared with a constant, it can appear
ungrouped:
SELECT x, y FROM tab2 WHERE y = 5 GROUP BY x;
I don't see why it should be allowed. I see the insist that y must be
unique value so it is ok to be
The way to reproduce:
CREATE OR REPLACE FUNCTION foobar(a integer[])
RETURNS SETOF int8 AS
$$
def getplan(name, query, args):
if SD.has_key(name):
plpy.warning(Using cached plan %s % name)
return SD[name]
plpy.warning(Prepare plan %s % name);
On Mon, Jun 7, 2010 at 6:41 PM, Stephen Frost sfr...@snowman.net wrote:
* Peter Eisentraut (pete...@gmx.net) wrote:
This is frequently requested by MySQL converts (and possibly others).
I'd certainly love to see it- but let's not confuse people by implying
that it would actually act the way
The linux kernel also uses it when it's availabe, see e.g.
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/arch/x86/crypto/crc32c-intel.c
If you guys are interested I have a Core i7 here, could run a little
benchmark.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Hi Takahiro,
Here is an updated version of the patch.
Thanks Magnus H for the help :)
1.4: Ported to head. Updated tests. Removed pg_stat_report.
2010/5/25 Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp
Joel Jacobson j...@gluefinance.com wrote:
I applied all the changes on 9.0beta
On Sun, Jun 6, 2010 at 10:24 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
I think that such parameters don't have optimal value for all the cases;
What makes you think that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via
Hi,
I tried getting the source using:
git clone http://git.postgresql.org/git/postgresql.git postgresql-git
but after a while (252MB) I always get:
[...]
Getting pack 61e1395a5bdacda95de5432123a0f8124fff05e6
which contains 476418893d3a2f366f47dbe4ce6d7522cc427545
error: Unable to get pack
On Tue, Jun 8, 2010 at 2:26 AM, Stephen Frost sfr...@snowman.net wrote:
Just an off-the-wall thought, but, would it be possible to have a tool
which read WAL backwards and compared entries in the WAL against entries
on disk? I realize that you'd only see one version of a particular
block and
On Tue, Jun 8, 2010 at 4:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
I have developed a patch that partially implements the functional
dependency feature that allows some columns to be omitted from the
GROUP BY clause if it can be shown that the columns
On Tue, Jun 8, 2010 at 12:40 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jun 6, 2010 at 10:24 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
I think that such parameters don't have optimal value for all the cases;
What makes you think that?
Actually the whole signature method is
* Greg Stark (gsst...@mit.edu) wrote:
I assume you mean back out the changes incrementally until you find a
full_page_write and see if it matches?
To be honest, you're already assuming I know more about how this all
works than I do. :) The gist of my thought was simply- we write out
block
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
But YAML is not human-readable. There are human-readable subsets of
it, but the general serializers do not produce them, and specific
serializers are difficult to get right (as we've seen).
No, it *is* human readable. Indeed, that's one of
Greg Stark gsst...@mit.edu writes:
On Tue, Jun 8, 2010 at 4:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The main objection to this is the same one I've had all along: it makes
the syntactic validity of a query dependent on what indexes exist for
the table. At minimum, that means that enforcing
On 6/8/2010 8:27 AM, Greg Stark wrote:
On Tue, Jun 8, 2010 at 2:26 AM, Stephen Frost sfr...@snowman.net wrote:
Just an off-the-wall thought, but, would it be possible to have a tool
which read WAL backwards and compared entries in the WAL against entries
on disk? I realize that you'd only see
On Tue, Jun 8, 2010 at 3:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, no, any cached plan will get invalidated if the index goes away.
The big problem with this implementation is that you could create a
*rule* (eg a view) containing a query whose validity depends on the
existence of an
Peter Eisentraut pete...@gmx.net writes:
On tis, 2010-06-08 at 09:59 +0900, Hitoshi Harada wrote:
In addition, what if y is implicitly a constant? For example,
SELECT x, y FROM tab2 WHERE y = a AND a = 5 GROUP BY x;
Yes, as I said, my implementation is incomplete in the sense that it
only
On 6/8/10 5:21 PM +0300, Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
On tis, 2010-06-08 at 09:59 +0900, Hitoshi Harada wrote:
In addition, what if y is implicitly a constant? For example,
SELECT x, y FROM tab2 WHERE y = a AND a = 5 GROUP BY x;
Yes, as I said, my implementation
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Perhaps the correct fix would be to mark stored query trees as having a
dependency on the index, so that dropping the index/constraint would
force a drop of the rule too. Just pushing the check to plan time, as
I suggested yesterday, isn't a very nice
On Tue, Jun 8, 2010 at 3:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The question is why bother to recognize *any* cases of this form.
I find it really semantically ugly to have the parser effectively
doing one deduction of this form when the main engine for that type
of deduction is elsewhere;
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Perhaps the correct fix would be to mark stored query trees as having a
dependency on the index, so that dropping the index/constraint would
force a drop of the rule too.
Alternatively, we could rewrite the rule
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Hm. The problem with that is that one of the benefits we'd like to get
from this is an efficiency win: the generated plan ought to only group
by the PK, not uselessly sort/group by everything in the row. I suppose
we could have the planner
Teodor Sigaev teo...@sigaev.ru writes:
The way to reproduce:
Well, of course plpython's error handling is fundamentally brain dead.
The immediate problem here seems to be that the PLy_error_in_progress
struct is stored in a memory context that's been cleared by the time
that control gets to the
All,
Selena (and others) have done a terrific job on the Open Items list for
9.0.:
http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
However, I haven't see much progress in the last 10 days on closing any
of these issues, and quite a few people have moved on to 9.1 features.
If you are
On Tue, Jun 8, 2010 at 8:53 AM, Greg Stark gsst...@mit.edu wrote:
On Tue, Jun 8, 2010 at 12:40 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jun 6, 2010 at 10:24 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
I think that such parameters don't have optimal value for all the cases;
The btree page deletion logic has a restriction that it cannot delete
the rightmost child page of any non-leaf btree page (see nbtree/README
for explanations). This is checked by _bt_parent_deletion_safe(),
which claims
* Note: it's OK to release page locks after checking, because a safe
*
I believe that the consensus was mostly in favor of deprecating = as
an operator name, with the intent to abolish it completely in a future
release. Attached is a patch to implement == as an alternative
operator name for hstore, and to make the backend throw a warning when
= is used as an
On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas robertmh...@gmail.com wrote:
I believe that the consensus was mostly in favor of deprecating = as
an operator name, with the intent to abolish it completely in a future
release. Attached is a patch to implement == as an alternative
operator name for
I wrote:
I realized this while thinking about Jeff Amiel's report here:
http://archives.postgresql.org/pgsql-general/2010-06/msg00351.php
I can't prove that this is what's causing his crashes, but it could
produce the symptom he's reporting.
Actually, no it can't: the case I'm envisioning
On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas robertmh...@gmail.com wrote:
I believe that the consensus was mostly in favor of deprecating = as
an operator name, with the intent to abolish it completely in a future
release.
2010/6/8 Merlin Moncure mmonc...@gmail.com:
On Tue, Jun 8, 2010 at 3:07 PM, Robert Haas robertmh...@gmail.com wrote:
I believe that the consensus was mostly in favor of deprecating = as
an operator name, with the intent to abolish it completely in a future
release. Attached is a patch to
Pavel Stehule pavel.steh...@gmail.com writes:
p.s. I hope so in 9.1 will be complete hstore module marked as deprecated
Really? And replaced with what? And why wouldn't the replacement use
the same operator names?
regards, tom lane
--
Sent via pgsql-hackers mailing
Josh Berkus j...@agliodbs.com writes:
Let's get 9.0 out the door, hey?
What we actually need is some testing effort. The lack of bug reports
against Hot Standby, in particular, is proof positive that no meaningful
testing is happening. (If you think it means HS is bug-free, I have a
nice
Tom Lane wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
p.s. I hope so in 9.1 will be complete hstore module marked as deprecated
Really? And replaced with what? And why wouldn't the replacement use
the same operator names?
Yeah. I'll be
On Tue, Jun 8, 2010 at 3:56 PM, Michael Glaesemann g...@seespotcode.net wrote:
On Jun 8, 2010, at 15:38 , Robert Haas wrote:
On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure mmonc...@gmail.com wrote:
hm. any chance of a shorter operator, like '#'? I kinda agree that
hstore_in and the operator
On Wed, May 26, 2010 at 11:24 PM, Joshua Tolley eggyk...@gmail.com wrote:
On Wed, May 26, 2010 at 03:47:25PM -0400, Robert Haas wrote:
On Tue, May 25, 2010 at 4:34 AM, Jonathan Leto jal...@gmail.com wrote:
This tiny doc patch adds _PG_init to the skeleton example code for a
PL. The
On Jun 8, 2010, at 15:38 , Robert Haas wrote:
On Tue, Jun 8, 2010 at 3:34 PM, Merlin Moncure mmonc...@gmail.com wrote:
hm. any chance of a shorter operator, like '#'? I kinda agree that
hstore_in and the operator don't have to be the same, but requiring
three letter token for the two most
On Jun 8, 2010, at 16:17 , Robert Haas wrote:
(That's enough bikeshedding for me.)
Test first, then post? :-)
What? :) If I was productively contributing, I wouldn't be bikeshedding, now
would I?
Michael Glaesemann
grzm seespotcode net
--
Sent via pgsql-hackers mailing list
On Thu, Jun 3, 2010 at 11:15 PM, Andrew Dunstan
andrew.duns...@pgexperts.com wrote:
The docs don't seem to contain any discussion I could find on why one might
not want hot_standby on. Maybe it's just too obvious to most people, but
this seems to be a bit lacking in the docs.
Well, if you
On Thu, May 27, 2010 at 9:22 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 27/05/10 12:39, Dimitri Fontaine wrote:
Greg Starkgsst...@mit.edu writes:
Fwiw I like the word replica but I don't see an obvious choice of
word to pair it with
I guess it's replica / origin,
Robert Haas wrote:
On Thu, Jun 3, 2010 at 11:15 PM, Andrew Dunstan
andrew.duns...@pgexperts.com wrote:
The docs don't seem to contain any discussion I could find on why one might
not want hot_standby on. Maybe it's just too obvious to most people, but
this seems to be a bit lacking in the
On Fri, 2010-06-04 at 10:18 -0400, Tom Lane wrote:
Jan Wieck janwi...@yahoo.com writes:
On 6/2/2010 3:10 PM, Alvaro Herrera wrote:
I'd prefer a setting that would tell the system to freeze all tuples
that fall within a safety range whenever any tuple in the page is frozen
-- weren't you
On Tue, Jun 8, 2010 at 4:55 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2010-06-04 at 10:18 -0400, Tom Lane wrote:
Jan Wieck janwi...@yahoo.com writes:
On 6/2/2010 3:10 PM, Alvaro Herrera wrote:
I'd prefer a setting that would tell the system to freeze all tuples
that fall within
On Tue, Jun 8, 2010 at 1:32 PM, Josh Berkus j...@agliodbs.com wrote:
However, I haven't see much progress in the last 10 days on closing any
of these issues, and quite a few people have moved on to 9.1 features.
I appreciate the effort that went into making this list, but it's not
very useful
On Tue, 2010-06-08 at 16:47 -0400, Robert Haas wrote:
On Thu, May 27, 2010 at 9:22 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 27/05/10 12:39, Dimitri Fontaine wrote:
Greg Starkgsst...@mit.edu writes:
Fwiw I like the word replica but I don't see an obvious
On Tue, Jun 8, 2010 at 4:54 PM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
On Thu, Jun 3, 2010 at 11:15 PM, Andrew Dunstan
andrew.duns...@pgexperts.com wrote:
The docs don't seem to contain any discussion I could find on why one
might
not want hot_standby on. Maybe it's
On Tue, 2010-06-08 at 16:58 -0400, Robert Haas wrote:
On Tue, Jun 8, 2010 at 4:55 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2010-06-04 at 10:18 -0400, Tom Lane wrote:
Jan Wieck janwi...@yahoo.com writes:
On 6/2/2010 3:10 PM, Alvaro Herrera wrote:
I'd prefer a setting that
On 6/8/10 2:01 PM, Robert Haas wrote:
I appreciate the effort that went into making this list, but it's not
very useful to work off of any more. The problem is that the set of
things that is listed here is pretty erratic - there are actual
problems that are not on this list, and there are
On Mon, Mar 22, 2010 at 11:58 AM, Greg Stark gsst...@mit.edu wrote:
On Thu, Mar 18, 2010 at 9:43 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-03-17 at 11:37 +0200, Heikki Linnakangas wrote:
One awkward omission in the new built-in standby mode, mainly used for
streaming
Andrew Dunstan and...@dunslane.net writes:
Well, yes. But then to stop that you could just lock users out using
pg_hba.conf, no? It just doesn't seem to be buying all that much to me.
The main reason to turn it off is to disable a whole lot of very poorly
tested code, and thereby improve the
On Tue, Jun 08, 2010 at 03:46:06PM -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Let's get 9.0 out the door, hey?
What we actually need is some testing effort. The lack of bug
reports against Hot Standby, in particular, is proof positive that
no meaningful testing is
On Tue, 2010-06-08 at 17:17 -0400, Robert Haas wrote:
On Mon, Mar 22, 2010 at 11:58 AM, Greg Stark gsst...@mit.edu wrote:
On Thu, Mar 18, 2010 at 9:43 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-03-17 at 11:37 +0200, Heikki Linnakangas wrote:
One awkward omission in the new
On Jun 8, 2010, at 12:34 PM, Merlin Moncure wrote:
hm. any chance of a shorter operator, like '#'? I kinda agree that
hstore_in and the operator don't have to be the same, but requiring
three letter token for the two most high traffic operations w/hstore
seems off to me.
# is currently
On Tue, Jun 8, 2010 at 5:13 PM, Josh Berkus j...@agliodbs.com wrote:
On 6/8/10 2:01 PM, Robert Haas wrote:
I appreciate the effort that went into making this list, but it's not
very useful to work off of any more. The problem is that the set of
things that is listed here is pretty erratic -
On Tue, Jun 8, 2010 at 5:08 PM, Simon Riggs si...@2ndquadrant.com wrote:
Why not just have a separate flag for HEAP_XMIN_FROZEN, that way we can
keep the xmin but also can see it is frozen?
We could do that, but I think the point of this exercise is to reduce
I/O - specifically, I/O caused
On Tue, 2010-06-08 at 18:03 -0400, Robert Haas wrote:
OK, yes, I see what you're getting at now. There are two possible
ways to do freeze the tuples and keep the xmin: we can either rely on
the PD_ALL_VISIBLE page-level bit (as I previously proposed) or we can
additionally have a
Whoa, there. There is not any way of moving forward with this list
without explaining why the list in its present form is not too useful.
Ah, the way I read your post was the list is not useful therefore I
will ignore it. From that perspective it was important for me to
respond to you lest
Robert Haas wrote:
On Mon, Mar 22, 2010 at 11:58 AM, Greg Stark gsst...@mit.edu wrote:
On Thu, Mar 18, 2010 at 9:43 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-03-17 at 11:37 +0200, Heikki Linnakangas wrote:
One awkward omission in the new built-in standby
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Well, yes. But then to stop that you could just lock users out using
pg_hba.conf, no? It just doesn't seem to be buying all that much to me.
The main reason to turn it off is to disable a whole lot of very poorly
tested
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2010-06-08 at 18:03 -0400, Robert Haas wrote:
OK, yes, I see what you're getting at now. There are two possible
ways to do freeze the tuples and keep the xmin: we can either rely on
the PD_ALL_VISIBLE page-level bit (as I previously proposed)
Andrew Dunstan and...@dunslane.net writes:
I prefer archive_cleanup_command. We should name things after their
principal function, not an implementation detail, IMNSHO.
Weak preference for archive_cleanup_command here.
More importantly, we should include an example in the docs. I created
Tom Lane wrote:
As for the language choice, my first thought is +1 for perl over shell,
mainly because it might be directly useful to people on Windows while
shell never would be. On the other hand, if it's possible to do a
useful one-liner in shell then let's do it that way.
I don't
Excerpts from Tom Lane's message of mar jun 08 18:35:00 -0400 2010:
But none of this accomplishes a damn thing towards the original goal,
which was to avoid an extra disk write associated with freezing (not
to mention an extra write for setting the transaction-committed hint
bit). Setting a
On Tue, Jun 8, 2010 at 6:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2010-06-08 at 18:03 -0400, Robert Haas wrote:
OK, yes, I see what you're getting at now. There are two possible
ways to do freeze the tuples and keep the xmin: we can either
On Tue, Jun 8, 2010 at 6:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
I prefer archive_cleanup_command. We should name things after their
principal function, not an implementation detail, IMNSHO.
Weak preference for archive_cleanup_command here.
OK,
On Tue, Jun 8, 2010 at 6:20 PM, Josh Berkus j...@agliodbs.com wrote:
If I simply start overhauling the list without explaining what I
perceive to be the systematic problems with it, then I will get yelled
at for failing to follow community process.
Nonsense. The one good thing about admin
Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 8, 2010 at 6:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
I prefer archive_cleanup_command. We should name things after their
principal function, not an implementation detail, IMNSHO.
Weak
On Tue, Jun 8, 2010 at 9:37 AM, Greg Sabino Mullane g...@turnstep.com wrote:
When I get some free time, I'll make a patch to implement as much of
the spec as we sanely can.
Saying that you'll fix it but not on any particular timetable is
basically equivalent to saying that you're not willing to
On Tue, Jun 8, 2010 at 9:45 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 8, 2010 at 6:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
I prefer archive_cleanup_command. We should name
On Wed, Jun 9, 2010 at 10:45 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 8, 2010 at 6:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
I prefer archive_cleanup_command. We should name
On Tue, Jun 8, 2010 at 1:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
Hmm.. is it worth going back to my proposal?
I don't recall exactly what proposal you might be referring to, but
http://archives.postgresql.org/pgsql-hackers/2010-01/msg00400.php
I'm
Robert Haas robertmh...@gmail.com wrote:
I think we're replacing restartpoint_command, not recovery_end_command.
Ah, sorry. I did the same replacement for restartpoint_command
in _, -, and camel case words.
BTW, should we also have a release note for the command?
I added a simple description
On Wed, Jun 2, 2010 at 10:24 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Jun 2, 2010 at 8:40 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 02/06/10 06:23, Fujii Masao wrote:
On Mon, May 31, 2010 at 7:17 PM, Fujii Masaomasao.fu...@gmail.com
wrote:
4) Change
On Tue, Jun 8, 2010 at 10:18 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Robert Haas robertmh...@gmail.com wrote:
I think we're replacing restartpoint_command, not recovery_end_command.
Ah, sorry. I did the same replacement for restartpoint_command
in _, -, and camel case
Fujii Masao wrote:
Tom's proposal is very small, but we cannot distinguish the password
for replication purpose from that for the real database named replication.
Is this OK? I can live with this as far as it's documented.
There is precedent for .pgpass being a bit ambiguous. See the way
Hello,
I'd like to experiment on compiling postgres with LLVM (either llvm-gcc or
clang) on Linux, is it supported ? Where should I start ?
Thanks ;)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstan and...@dunslane.net wrote:
There is precedent for .pgpass being a bit ambiguous. See the way
localhost is used.
OK. The attached patch allows us to use replication in the database
field of the .pgpass file, for the replication connection.
82 matches
Mail list logo
