Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> PQping is supposed to be smarter about classifying errors
> >> than this.
>
> > I was not aware this was discussed last week because I am behind on
> > email. I was fixing a report from a month ago. I did explain how I was
> > doi
Bruce Momjian writes:
> Tom Lane wrote:
>> PQping is supposed to be smarter about classifying errors
>> than this.
> I was not aware this was discussed last week because I am behind on
> email. I was fixing a report from a month ago. I did explain how I was
> doing the tests.
Um, you did respo
Tom Lane wrote:
> I wrote:
> > The reason this is a problem is that somebody, in a fit of inappropriate
> > optimization, took out the code that allowed canAcceptConnections to
> > distinguish the "not consistent yet" state.
>
> Oh, no, that's not the case --- the PM_RECOVERY postmaster state does
On Fri, Nov 26, 2010 at 6:30 PM, Tom Lane wrote:
> Speaking of classifying errors, should we have a fourth result value to
> cover "obviously bogus parameters"?
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing lis
I wrote:
> The reason this is a problem is that somebody, in a fit of inappropriate
> optimization, took out the code that allowed canAcceptConnections to
> distinguish the "not consistent yet" state.
Oh, no, that's not the case --- the PM_RECOVERY postmaster state does
still distinguish not-ready
Bruce Momjian writes:
> Fujii Masao wrote:
>> This patch breaks the behavior that "pg_ctl -w start" waits until the standby
>> has been ready to accept read-only queries. IOW, pg_ctl without this patch
>> continues to check the connection even if the connection is rejected because
>> the database
Bruce Momjian writes:
> Fujii Masao wrote:
>> I agree to treat the receipt of password request from the server as success
>> of the server starting. But I don't think that we should treat other
>> rejection
>> cases that way and change the existing behavior.
> OK, that is easy to fix.
It's wron
Hey hackers,
I am sorry, but is it possible to implement BTW ability to
check exactly status of authentication from libpq ? As for now,
the only way to check failed authentication is parsing the error
message, that is sadly.
2010/11/26 Bruce Momjian
> Fujii Masao wrote:
> > On Fri, Nov 26, 2010
Fujii Masao wrote:
> On Fri, Nov 26, 2010 at 3:11 AM, Bruce Momjian wrote:
> > I have applied this patch, with modified wording of the "cannot connect"
> > case:
> >
> > ? ? ? ?$ pg_ctl -w -l /dev/null start
> > ? ? ? ?waiting for server to start done
> > ? ? ? ?server started
> > ? ? ? ?warni
On Fri, Nov 26, 2010 at 3:11 AM, Bruce Momjian wrote:
> I have applied this patch, with modified wording of the "cannot connect"
> case:
>
> $ pg_ctl -w -l /dev/null start
> waiting for server to start done
> server started
> warning: could not connect, perhaps due
Bruce Momjian wrote:
> > > BTW, it is annoying that we can't definitively distinguish "postmaster
> > > is not running" from a connectivity problem, but I can't see a way
> > > around that.
> >
> > Agreed. I will research this.
>
> I have researched this and developed the attached patch. It imp
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> Possibly the cleanest fix is to implement pg_ping as a libpq function.
> > >> You do have to distinguish connection failures (ie connection refused)
> > >> from errors that came back from the postmaster,
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Possibly the cleanest fix is to implement pg_ping as a libpq function.
> >> You do have to distinguish connection failures (ie connection refused)
> >> from errors that came back from the postmaster, and the easiest place to
> >> be
Bruce Momjian writes:
> Tom Lane wrote:
>> Possibly the cleanest fix is to implement pg_ping as a libpq function.
>> You do have to distinguish connection failures (ie connection refused)
>> from errors that came back from the postmaster, and the easiest place to
>> be doing that is inside libpq.
Tom Lane wrote:
> Bruce Momjian writes:
> > Agreed. So how do we pass that info to libpq without exceeding the
> > value of fixing this problem? Should we parse pg_controldata output?
> > pg_upgrade could use machine-readable output from that too.
>
> pg_controldata seems 100% unrelated to thi
Bruce Momjian writes:
> Agreed. So how do we pass that info to libpq without exceeding the
> value of fixing this problem? Should we parse pg_controldata output?
> pg_upgrade could use machine-readable output from that too.
pg_controldata seems 100% unrelated to this problem. You cannot even
Tom Lane wrote:
> Magnus Hagander writes:
> > On Wed, Nov 17, 2010 at 19:57, Bruce Momjian wrote:
> >> Is FATAL, in general, enough to conclude the server is running?
>
> > No - specifically, we will send FATAL when "the database system is
> > starting up", which is exactly the one we want to *a
Magnus Hagander writes:
> On Wed, Nov 17, 2010 at 19:57, Bruce Momjian wrote:
>> Is FATAL, in general, enough to conclude the server is running?
> No - specifically, we will send FATAL when "the database system is
> starting up", which is exactly the one we want to *avoid*.
> I think we should
On Wed, Nov 17, 2010 at 19:57, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On Wed, Nov 17, 2010 at 19:50, Bruce Momjian wrote:
>> > Magnus Hagander wrote:
>> >> Does this actually solve the *problem*, though? The problem is not
>> >> what is reported ?on stdout/stderr, the problem is that th
Magnus Hagander wrote:
> On Wed, Nov 17, 2010 at 19:50, Bruce Momjian wrote:
> > Magnus Hagander wrote:
> >> Does this actually solve the *problem*, though? The problem is not
> >> what is reported ?on stdout/stderr, the problem is that the net result
> >> is that the server is reported as not sta
On Wed, Nov 17, 2010 at 19:50, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> Does this actually solve the *problem*, though? The problem is not
>> what is reported on stdout/stderr, the problem is that the net result
>> is that the server is reported as not started (by the service control
>> m
Magnus Hagander wrote:
> > I basically report the connection error string if it starts with "FATAL:".
> >
> > I originally tried to check for an ERRCODE_INVALID_PASSWORD error field
> > (see // comments), but it seems there is no way to access this, i.e.
> > PQgetResult(conn) on a connection failur
On Fri, Nov 12, 2010 at 17:47, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > Uh, I still cannot reproduce the failure:
>>
>> I would imagine you need -w option on the start. The whole issue
>> here is whether start's wait-for-server-start code works.
>
> Thanks, I am now a
Tom Lane wrote:
> Bruce Momjian writes:
> > Uh, I still cannot reproduce the failure:
>
> I would imagine you need -w option on the start. The whole issue
> here is whether start's wait-for-server-start code works.
Thanks, I am now able to reproduce this. I was able to get this to
report the .
Bruce Momjian writes:
> Uh, I still cannot reproduce the failure:
I would imagine you need -w option on the start. The whole issue
here is whether start's wait-for-server-start code works.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
Magnus Hagander wrote:
> On Fri, Nov 12, 2010 at 03:49, Bruce Momjian wrote:
> > Magnus Hagander wrote:
> >> On Fri, Sep 17, 2010 at 05:51, Ashesh Vashi
> >> wrote:
> >> > Hi Mark,
> >> >
> >> > On of my college (Sujeet) has found a way to reproduce the same
> >> > behaviour.
> >> > 1. Installed
On Fri, Nov 12, 2010 at 03:49, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On Fri, Sep 17, 2010 at 05:51, Ashesh Vashi
>> wrote:
>> > Hi Mark,
>> >
>> > On of my college (Sujeet) has found a way to reproduce the same behaviour.
>> > 1. Installed PG 9.0 on Win XP SP3
>> > 2. Stop the Postgres
Magnus Hagander wrote:
> On Fri, Sep 17, 2010 at 05:51, Ashesh Vashi
> wrote:
> > Hi Mark,
> >
> > On of my college (Sujeet) has found a way to reproduce the same behaviour.
> > 1. Installed PG 9.0 on Win XP SP3
> > 2. Stop the Postgresql-9.0 service from service manager console
> > 3. Create pgpa
On 09/24/2010 11:11 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/24/2010 10:15 AM, Magnus Hagander wrote:
In that case, we should probably teach pg_ctl about this case, no?
Since it clearly gives an incorrect message to the user now...
pg_ctl decides that the server is running iff it ca
Dave Page writes:
> On Fri, Sep 24, 2010 at 4:11 PM, Tom Lane wrote:
>> (Of course, a "pg_ping" utility would be a better answer, but nobody's
>> gotten around to that in more than ten years, so I'm not holding my
>> breath.)
> Hmm, that sounded like it could be my 9.1 mini project - then Google
On Fri, Sep 24, 2010 at 4:11 PM, Tom Lane wrote:
> (Of course, a "pg_ping" utility would be a better answer, but nobody's
> gotten around to that in more than ten years, so I'm not holding my
> breath.)
Hmm, that sounded like it could be my 9.1 mini project - then Google
showed me that SeanC wro
Andrew Dunstan writes:
> On 09/24/2010 10:15 AM, Magnus Hagander wrote:
>> In that case, we should probably teach pg_ctl about this case, no?
>> Since it clearly gives an incorrect message to the user now...
> pg_ctl decides that the server is running iff it can connect to it. Do
> you intend to
On 09/24/2010 10:15 AM, Magnus Hagander wrote:
On Fri, Sep 24, 2010 at 16:04, Tom Lane wrote:
Magnus Hagander writes:
I took a quick look at the code, and from what I can tell this is
because PQconnectionNeedsPassword() always returns false if a
pgpass.conf has been used. There is no handli
On Fri, Sep 24, 2010 at 16:04, Tom Lane wrote:
> Magnus Hagander writes:
>> I took a quick look at the code, and from what I can tell this is
>> because PQconnectionNeedsPassword() always returns false if a
>> pgpass.conf has been used. There is no handling the case where pgpass
>> is used, but h
Magnus Hagander writes:
> I took a quick look at the code, and from what I can tell this is
> because PQconnectionNeedsPassword() always returns false if a
> pgpass.conf has been used. There is no handling the case where pgpass
> is used, but has an incorrect password.
Why should it? That code i
On Fri, Sep 17, 2010 at 05:51, Ashesh Vashi
wrote:
> Hi Mark,
>
> On of my college (Sujeet) has found a way to reproduce the same behaviour.
> 1. Installed PG 9.0 on Win XP SP3
> 2. Stop the Postgresql-9.0 service from service manager console
> 3. Create pgpass.conf in postgres (service account) u
36 matches
Mail list logo
