Simon Riggs wrote:
Taking snapshots from primary has a few disadvantages
...
* snapshots on primary prevent row removal (but this was also an
advantage of this technique!)
That makes it an awful solution for high availability. A backend hung in
transaction-in-progress state in
David Rowley wrote:
The thing that surprised me was that string_to_array didn't perform as well.
I expected single character searches to perform a little better. I can't
think why it would be slower now.
Yes, that's strange. I tried to reproduce that here, with a CVS snapshot
before the
On Thu, 2008-09-11 at 09:24 +0300, Heikki Linnakangas wrote:
I like the idea of acquiring snapshots locally in the slave much more.
As you mentioned, the options there are to defer applying WAL, or cancel
queries.
More exotic ways to defer applying WAL include using some smart
filesystems
Hi,
I have noticed two different coding conventions being followed in
postgres code base.
See e.g. function names in syslogger.c
static void set_next_rotation_time(void);
static void sigHupHandler(SIGNAL_ARGS);
and variable names in the same file
int bytes_in_logbuffer = 0;
char
On Thu, 2008-09-11 at 09:24 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
Taking snapshots from primary has a few disadvantages
...
* snapshots on primary prevent row removal (but this was also an
advantage of this technique!)
That makes it an awful solution
Abbas wrote:
I have noticed two different coding conventions being followed in
postgres code base.
See e.g. function names in syslogger.c
static void set_next_rotation_time(void);
static void sigHupHandler(SIGNAL_ARGS);
and variable names in the same file
int bytes_in_logbuffer = 0;
char
Heikki Linnakangas wrote:
Simon Riggs wrote:
Taking snapshots from primary has a few disadvantages
...
* snapshots on primary prevent row removal (but this was also an
advantage of this technique!)
That makes it an awful solution for high availability. A backend hung in
ITAGAKI Takahiro wrote:
Here is a revised version of the pgbench duration patch.
Looking at the Win32 timer implementation, it's a bit different from the
one we have in src/backend/port/win32/timer.c. The one in timer.c uses a
separate thread and WaitForSingleObjectEx() to wait, while your
Abbas wrote:
Hi,
I have noticed two different coding conventions being followed in
postgres code base.
See e.g. function names in syslogger.c
static void set_next_rotation_time(void);
static void sigHupHandler(SIGNAL_ARGS);
and variable names in the same file
int bytes_in_logbuffer =
On Thu, 2008-09-11 at 11:11 +0100, Richard Huxton wrote:
I have to say I agree with Heikki here. Blocking the master based on
what the slave is doing seems to make host standby less useful than warm.
I agree also, that why I flagged it up for discussion.
--
Simon Riggs
Heikki Linnakangas wrote:
ITAGAKI Takahiro wrote:
Here is a revised version of the pgbench duration patch.
Looking at the Win32 timer implementation, it's a bit different from the
one we have in src/backend/port/win32/timer.c. The one in timer.c uses a
separate thread and
Abbas [EMAIL PROTECTED] writes:
While writing code or reviewing a path are we supposed to consider the
camel cased names correct or the under-score separated names correct?
Some parts of the code use the two to distinguish between functions local to
that module and functions that are part of
Pavan Deolasee [EMAIL PROTECTED] writes:
On Wed, Sep 10, 2008 at 9:22 PM, Tom Lane [EMAIL PROTECTED] wrote:
On reflection I'm not even sure that this is strictly an autovacuum
bug. It can be cast more generically as RecentGlobalXmin getting
used without ever having been set, and it sure looks
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-09-11 at 11:11 +0100, Richard Huxton wrote:
I have to say I agree with Heikki here. Blocking the master based on
what the slave is doing seems to make host standby less useful than warm.
I agree also, that why I flagged it up for
Robert Haas wrote:
A good start might be to always OUTPUT memory parameters using the
same base unit.
SHOW gives output that matches what you input.
Not for me it doesn't.
portal=# show temp_buffers;
temp_buffers
--
1024
(1 row)
portal=# set temp_buffers = '16MB';
SET
portal=#
Gregory Stark [EMAIL PROTECTED] writes:
Abbas [EMAIL PROTECTED] writes:
While writing code or reviewing a path are we supposed to consider the
camel cased names correct or the under-score separated names correct?
Some parts of the code use the two to distinguish between functions local to
I have question about FSM structure on the page. If I look into the code it
seems to me that tree structure is degenerated on the right side. It is
probably space optimization because complete tree needs BLCKSZ/2 space on the
page and rest is empty.
Is my assumption correct? If yes maybe
Zdenek Kotala wrote:
I have question about FSM structure on the page. If I look into the code
it seems to me that tree structure is degenerated on the right side.
It is probably space optimization because complete tree needs BLCKSZ/2
space on the page and rest is empty.
Is my assumption
Peter Eisentraut [EMAIL PROTECTED] writes:
temp_buffers is actually special-cased in the code because
/*
* We show the GUC var until local buffers have been initialized, and
* NLocBuffer afterwards.
*/
It is not clear to me right now why that is a good idea.
I think the
Alvaro Herrera wrote:
So I went ahead and moved its mention to a separate question, where it
has a lot more visibility. (I also added an URL to anoncvs, where
people can see it more readily.)
Perhaps the low visibility also has to do with the fact that
documentation is hidden under tools.
Another question:
Does we need random_bool to spread workload? It seems to me a useless, because
it also invokes one backend to use more pages instead of using one which is
already in buffer cache. I think that it should generate a lot of extra i/o. Do
not forget WAL full page write for
Alvaro Herrera [EMAIL PROTECTED] writes:
Actually, 8.2 initializes it to InvalidTransactionId too, so it doesn't
seem like there's a problem there either. Since the problem stems from
using it as initializer for the Min() calculation, there's no actual bug
on 8.2 either. The bug only
On Thu, Sep 11, 2008 at 7:18 AM, Gregory Stark [EMAIL PROTECTED] wrote:
a) transactions with live snapshots on the slave prevent the master from being
able to vacuum tuples (which defeats the purpose of having a live standby
server for some users).
or
b) vacuum on the server which
temp_buffers is actually special-cased in the code because
/*
* We show the GUC var until local buffers have been initialized, and
* NLocBuffer afterwards.
*/
It is not clear to me right now why that is a good idea. But it is only
this one paramter.
OK, well that's not so bad
Merlin Moncure wrote:
There is nothing stopping you from setting up two (or more) slave
servers, with one designated as failover that doens't serve queries,
right?
I'd imagine that even if applying the WAL on the slave is blocked, it's
still streamed from the master to the slave, and in case
On Thu, 2008-09-11 at 15:23 +0300, Heikki Linnakangas wrote:
I'd imagine that even if applying the WAL on the slave is blocked, it's
still streamed from the master to the slave, and in case of failover the
slave will fast-forward before starting up as the new master.
Which begs the question:
Gregory Stark wrote:
b) vacuum on the server which cleans up a tuple the slave has in scope has to
block WAL reply on the slave (which I suppose defeats the purpose of having
a live standby for users concerned more with fail-over latency).
One problem with this, BTW, is that if there's a
Csaba Nagy wrote:
On Thu, 2008-09-11 at 15:23 +0300, Heikki Linnakangas wrote:
I'd imagine that even if applying the WAL on the slave is blocked, it's
still streamed from the master to the slave, and in case of failover the
slave will fast-forward before starting up as the new master.
Which
On Wed, Sep 10, 2008 at 11:13 PM, Markus Wanner [EMAIL PROTECTED] wrote:
Which signal should we use for the notification to the backend from
WAL sender? The notable signals are already used.
I'm using SIGUSR1, see src/backend/storage/ipc/imsg.c from Postgres-R, line
232. That isn't is use for
On Thu, 2008-09-11 at 15:42 +0300, Heikki Linnakangas wrote:
One problem with this, BTW, is that if there's a continuous stream of
medium-length transaction in the slave, each new snapshot taken will
prevent progress in the WAL replay, so the WAL replay will advance in
baby steps, and can
Fujii Masao [EMAIL PROTECTED] writes:
Which signal should WAL sender send to backends?
Sooner or later we shall have to bite the bullet and set up a
multiplexing system to transmit multiple event types to backends with
just one signal. We already did it for signals to the postmaster.
Hi,
Fujii Masao wrote:
Umm... backends have already used SIGUSR1. PostgresMain() sets up a signal
handler for SIGUSR1 as follows.
Uh.. right. Thanks for pointing that out. Maybe just use SIGPIPE for now?
Yes, since WAL sender waits on select(), it's convenient to use signal
for the
Hi,
Tom Lane wrote:
Sooner or later we shall have to bite the bullet and set up a
multiplexing system to transmit multiple event types to backends with
just one signal. We already did it for signals to the postmaster.
Agreed. However, it's non-trivial if you want reliable queues (i.e. no
On Thu, Sep 11, 2008 at 2:07 AM, Simon Riggs wrote:
Transaction snapshots is probably the most difficult problem for Hot
Standby to resolve.
* remotely from primary node
* locally on the standby node
If we derive a snapshot locally, then we will end up with a situation
where the
Csaba Nagy wrote:
On Thu, 2008-09-11 at 15:42 +0300, Heikki Linnakangas wrote:
One problem with this, BTW, is that if there's a continuous stream of
medium-length transaction in the slave, each new snapshot taken will
prevent progress in the WAL replay, so the WAL replay will advance in
baby
I'd imagine that even if applying the WAL on the slave is blocked, it's
still streamed from the master to the slave, and in case of failover the
slave will fast-forward before starting up as the new master. Of course, if
it has fallen 3 days behind because of a giant reporting query, it can
On Thu, 2008-09-11 at 16:19 +0300, Heikki Linnakangas wrote:
Well, yes, but you can fall behind indefinitely that way. Imagine that
each transaction on the slave lasts, say 10 minutes, with a new
transaction starting every 5 minutes. On the master, there's a table
that's being vacuumed (or
Le jeudi 11 septembre 2008, Heikki Linnakangas a écrit :
Well, yes, but you can fall behind indefinitely that way. Imagine that
each transaction on the slave lasts, say 10 minutes, with a new
transaction starting every 5 minutes. On the master, there's a table
that's being vacuumed (or
On Thu, 2008-09-11 at 15:33 +0200, Dimitri Fontaine wrote:
What would forbid the slave to choose to replay all currently lagging WALs
each time it's given the choice to advance a little?
Well now that I think I understand what Heikki meant, I also think the
problem is that there's no choice at
Le jeudi 11 septembre 2008, Csaba Nagy a écrit :
Well now that I think I understand what Heikki meant, I also think the
problem is that there's no choice at all to advance, because the new
queries will simply have the same snapshot as currently running ones as
long as WAL reply is blocked...
Csaba Nagy wrote:
and that means in fact that if you have
continuously overlapping small transactions, the blocking horizon
could be even blocked forever, as there'll always be a query running,
and the new queries will always have the snapshot of the currently
running ones because WAL recovery
Thanks for the detailed thinking. At least one very good new idea here,
some debate on other points.
On Thu, 2008-09-11 at 09:24 +0300, Heikki Linnakangas wrote:
And still we can't escape the scenario that the slave receives a WAL
record that vacuums away a tuple that's still visible
Peter Eisentraut wrote:
Alvaro Herrera wrote:
So I went ahead and moved its mention to a separate question, where it
has a lot more visibility. (I also added an URL to anoncvs, where
people can see it more readily.)
Perhaps the low visibility also has to do with the fact that
Simon Riggs wrote:
So part of the handshake between
primary and standby must be what is your recentxmin?. The primary will
then use the lower/earliest of the two.
Even then, the master might already have vacuumed away tuples that are
visible to an already running transaction in the slave,
On Thu, Sep 11, 2008 at 3:17 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Wed, 2008-09-10 at 17:57 +0900, Fujii Masao wrote:
My sequence covers several cases :
* There is no missing WAL file.
* There is a lot of missing WAL file.
This is the likely case for any medium+ sized database.
I'm
Fujii Masao wrote:
I think that this case would often happen. So, we should establish a certain
solution or procedure to the case where TLI of the master doesn't match
TLI of the slave. If we only allow the case where TLI of both servers is the
same, the configuration after failover always needs
Jorgen Austvik - Sun Norway wrote:
The attached patch makes pg_regress write converted files to
inputdir/sql and inputdir/expected, which is one way to make it read
and write to the same directory. Tested on Solaris x86 with pgsql make
check and standalone.
Okay, so this patch does
Markus Wanner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Sooner or later we shall have to bite the bullet and set up a
multiplexing system to transmit multiple event types to backends with
just one signal. We already did it for signals to the postmaster.
Agreed. However, it's non-trivial if
ITAGAKI Takahiro wrote:
***
*** 29,36
--- 29,40
#include postgres_fe.h
#include libpq-fe.h
+ #include pqsignal.h
#include ctype.h
+ #include signal.h
+ #include sys/time.h
+ #include unistd.h
#ifdef WIN32
#undef FD_SETSIZE
sys/time.h and unistd.h are
Hi,
Tom Lane wrote:
No, that's not what I had in mind at all, just the ability to deliver
one of a specified set of event notifications --- ie, get around the
fact that Unix only gives us two user-definable signal types.
Ah, okay. And I already thought you'd like imessages :-(
For signals
Lawrence, Ramon [EMAIL PROTECTED] writes:
To keep the changes simple, the update simply calls
ExecChooseHashTableSize() in create_hashjoin_plan() to re-calculate the
expected number of batches. This is more efficient and results in less
code changes than modifying the HashPath struct to store
Heikki Linnakangas [EMAIL PROTECTED] writes:
BTW, we haven't talked about how to acquire a snapshot in the slave. You'll
somehow need to know which transactions have not yet committed, but will in
the
future.
I'm not sure why you need to know which ones will commit in the future. ISTM
you
Tom Lane [EMAIL PROTECTED] writes:
I'm not sure what to do if we need signals sent from processes that
aren't connected to shared memory; but maybe we need not cross that
bridge here.
Such as signals coming from the postmaster? Isn't that where most of them come
from though?
--
Gregory
On Tue, 2008-09-02 at 12:47 -0400, Alvaro Herrera wrote:
Unknown SDATA: [mdash ]
at /usr/share/sgml/docbook/utils-0.6.14/helpers//docbook2man-spec.pl
line 1241, STDIN line 11975.
Please see here:
http://archives.postgresql.org/message-id/20080821130203.GN4169%
40alvh.no-ip.org
FWIW,
Gregory Stark wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
BTW, we haven't talked about how to acquire a snapshot in the slave. You'll
somehow need to know which transactions have not yet committed, but will in the
future.
I'm not sure why you need to know which ones will commit in
Brendan Jurd [EMAIL PROTECTED] writes:
I've attached a new version of the patch (version 3), as well as an
incremental patch to show the differences between versions 2 and 3.
Applied with minimal modifications. I changed a couple of error
messages that didn't seem to meet the style guidelines,
[EMAIL PROTECTED] (Heikki Linnakangas) writes:
Simon Riggs wrote:
Taking snapshots from primary has a few disadvantages
...
* snapshots on primary prevent row removal (but this was also an
advantage of this technique!)
That makes it an awful solution for high availability. A
On Fri, Sep 12, 2008 at 3:34 AM, Tom Lane [EMAIL PROTECTED] wrote:
Applied with minimal modifications. I changed a couple of error
messages that didn't seem to meet the style guidelines,
Great, thanks Tom. And thanks again to Alex and Martijn for helping
me refine the patch.
and I moved all
Josh Berkus [EMAIL PROTECTED] writes:
Also, note that the following patches need performance testing on a
variety of platforms. Everyone should help with this.
GSoC Improved Hash Indexing
posix fadvises
operator restrictivity function for text search
CLUSTER using sort instead of index
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Here is a patch to user NDirectFileRead/Write counters to get I/O counts
in BufFile module. We can see the counters when log_statement_stats is on.
Couple thoughts here:
* Let's rename them BufFileReadCount and BufFileWriteCount to reflect
their
Back in February, Tom said here:
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00963.php :
That defeats a couple of optimizations that
Simon put in recently. The one for no XLOG during COPY is not too
hard to see how to re-enable, but I'm not sure what else there was.
Could
On Thu, Sep 11, 2008 at 9:01 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Could someone please point me at where this optimization was committed? I'm
having trouble locating it.
I think it's this one:
http://archives.postgresql.org/pgsql-committers/2007-01/msg00296.php
--
Guillaume
--
Sent
Andrew Dunstan wrote:
Back in February, Tom said here:
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00963.php :
That defeats a couple of optimizations that
Simon put in recently. The one for no XLOG during COPY is not too
hard to see how to re-enable, but I'm not sure what else
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
Back in February, Tom said here:
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00963.php :
That defeats a couple of optimizations that
Simon put in recently. The one for no XLOG during COPY is not too
hard to see how to re-enable,
On Thu, Sep 11, 2008 at 1:53 AM, Josh Berkus [EMAIL PROTECTED] wrote:
Some patches have not been assigned to reviewers for various reasons. The
following weren't assigned because they are complex and really need a
high-end hacker or committer to take them on:
libpq events
Alvaro actually
Merlin Moncure escribió:
On Thu, Sep 11, 2008 at 1:53 AM, Josh Berkus [EMAIL PROTECTED] wrote:
Some patches have not been assigned to reviewers for various reasons. The
following weren't assigned because they are complex and really need a
high-end hacker or committer to take them on:
Alvaro Herrera wrote:
Actually a minor gripe ... should PQsetvalue be PQsetValue? :-)
We were mimicing PQgetvalue, which uses a lowercase 'v'. Is there a
preference, none on this end.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
I'm not sure what to do if we need signals sent from processes that
aren't connected to shared memory; but maybe we need not cross that
bridge here.
Such as signals coming from the postmaster? Isn't that where most of them come
from
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Here is an updated version of the Copy storage parameters patch.
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01417.php
I looked this over and feel that it still needs work. The
implementation seems appropriate for columns coming from LIKE
Hi Magnus,
Josh has assigned your patch to me for an initial review.
First up I'd like to say that this is a really nice upgrade.
Shielding a running server from reloading a bogus conf file makes a
whole lot of sense.
On Sun, Aug 17, 2008 at 1:47 AM, Magnus Hagander [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Merlin Moncure escribió:
Alvaro actually performed a review on libpq events. We are waiting on
his feedback on our changes (based on his review) and the newly
submitted documentation. I'll update the wiki accordingly. I wasn't
sure if Alvaro was
On Thu, Sep 11, 2008 at 5:06 PM, Tom Lane [EMAIL PROTECTED] wrote:
The patch looks OK to me as it was the last time I looked at it; maybe
Tom has more comments, so I decided against just committing it.
I haven't got round to looking at it in this fest. If anyone else wants
to look it over,
Heikki Linnakangas [EMAIL PROTECTED] writes:
sys/time.h and unistd.h are #included just a few lines after that, but
within a #ifndef WIN32 block. I don't think the patch added any
codepaths where we'd need those header files on Windows, so I presume
that was just an oversight and those two
Josh is probably basing that on the long history of
discussion/revision cycles.
Yep, and that *I* don't understand what the patch does, so I'm not going to
turn a newbie reviewer loose on it.
--
--Josh
Josh Berkus
PostgreSQL
San Francisco
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Kevin Grittner [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
I am not sure about some of the corner cases --- anyone want to see if
their understanding of the spec for interval string is different?
The patch seems to support extensions to the standard.
Right.
Josh Berkus wrote:
Josh is probably basing that on the long history of
discussion/revision cycles.
Yep, and that *I* don't understand what the patch does, so I'm not going to
turn a newbie reviewer loose on it.
Here is a quick overview, there are two parts to the patch:
1. event system
Ron Mayer [EMAIL PROTECTED] writes:
Back a while ago (2003) there was some talk about replacing
some of the non-standard extensions with shorthand forms of
intervals with ISO 8601 intervals that have a similar but
not-the-same shorthand.
I think *replacement* would be a hard sell, as that
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Back a while ago (2003) there was some talk about replacing
some of the non-standard extensions with shorthand forms of
intervals with ISO 8601 intervals that have a similar but
not-the-same shorthand.
I think *replacement* would be a hard
I wrote:
Are people satisfied that the Windows part of the patch is okay?
I went ahead and applied this patch after some trivial stylistic fixes.
The buildfarm will soon tell us if the WIN32 part of the patch compiles,
but not whether it works --- would someone double-check the functioning
of
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think *replacement* would be a hard sell, as that would tick off all
the existing users ;-). Now it seems like being able to accept either
I originally submitted a patch that supported both, and I think
you suggested replacing on the
Tom Lane wrote:
The other problem is that the SQL spec clearly defines an interval
literal syntax, and it's not this ISO thing. So even without backward
compatibility issues, 8601-only doesn't seem like it would fly.
Oh. I wasn't proposing 8601-only. Just the one-character
shorthands like
Ron Mayer [EMAIL PROTECTED] writes:
Oh. I wasn't proposing 8601-only. Just the one-character
shorthands like '1Y1M'::interval that postgresql interprets
as 1 year one minute. No standard specifies anything close
to that; and any similar standards ask to interpret that M as
months instead
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
'1Y1M'::interval ... minute ... month
Hmmm. I would say that the problem with that is not that it's
nonstandard but that it's ambiguous.
Ah yes.
Our documentation...says...or abbreviations.
...What if we just tweak the code to
reject
Folks,
Far and away the most common question we get in IRC includes phrases
like:
psql: FATAL: Ident authentication failed for user root
This isn't exactly informative to newbies, so I'm proposing a patch
like that attached for such failures. Instead of seeing that
mysterious message,
David Fetter [EMAIL PROTECTED] writes:
This isn't exactly informative to newbies, so I'm proposing a patch
like that attached for such failures. Instead of seeing that
mysterious message, they'd get something like this:
psql: FATAL: Ident authentication failed for user root
HINT:
On Thu, 11 Sep 2008 22:59:40 -0400
Tom Lane [EMAIL PROTECTED] wrote:
psql: FATAL: Ident authentication failed for user root
HINT: Is pg_hba.conf set properly on the server?
Seems pretty useless. What does set properly mean? There isn't
even any good reason to think that the
On Thu, Sep 11, 2008 at 08:10:45PM -0700, Joshua D. Drake wrote:
On Thu, 11 Sep 2008 22:59:40 -0400
Tom Lane [EMAIL PROTECTED] wrote:
psql: FATAL: Ident authentication failed for user root
HINT: Is pg_hba.conf set properly on the server?
Seems pretty useless. What does
Joshua Drake [EMAIL PROTECTED] writes:
I think something like:
psql: FATAL: Ident authentication failed for user root
HINT: http://www.postgresql.org/docs/8.3/static/client-authentication.html
Would be nice.
Do you really think that's helpful in the typical case where someone
fat-fingered
On Thu, Sep 11, 2008 at 11:28:36PM -0400, Tom Lane wrote:
Joshua Drake [EMAIL PROTECTED] writes:
I think something like:
psql: FATAL: Ident authentication failed for user root
HINT: http://www.postgresql.org/docs/8.3/static/client-authentication.html
Would be nice.
Do you really
On Thu, Sep 11, 2008 at 11:28:36PM -0400, Tom Lane wrote:
Joshua Drake [EMAIL PROTECTED] writes:
I think something like:
psql: FATAL: Ident authentication failed for user root
HINT: http://www.postgresql.org/docs/8.3/static/client-authentication.html
Would be nice.
Do you really
Tom Lane wrote:
Joshua Drake [EMAIL PROTECTED] writes:
I think something like:
psql: FATAL: Ident authentication failed for user root
HINT: http://www.postgresql.org/docs/8.3/static/client-authentication.html
Would be nice.
Do you really think that's helpful in the typical case where
David Fetter wrote:
On Thu, Sep 11, 2008 at 11:28:36PM -0400, Tom Lane wrote:
Joshua Drake [EMAIL PROTECTED] writes:
I think something like:
psql: FATAL: Ident authentication failed for user root
HINT: http://www.postgresql.org/docs/8.3/static/client-authentication.html
Would be nice.
Do you
92 matches
Mail list logo
