| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>, Mark Llewellyn <mark_llewellyn(at)adp(dot)com>, pgsql-hackers(at)postgresql(dot)org, Sujeet Rajguru <sujeet(dot)rajguru(at)enterprisedb(dot)com> |
| Subject: | Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running |
| Date: | 2010-11-26 23:30:03 |
| Message-ID: | 5594.1290814203@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
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 from ready. The real problem is that what
Bruce implemented has practically nothing to do with what was discussed
last week. PQping is supposed to be smarter about classifying errors
than this.
Speaking of classifying errors, should we have a fourth result value to
cover "obviously bogus parameters"? Right now you'll get PQNORESPONSE
for cases like incorrect syntax in the conninfo string. I'm not sure
how tense we ought to try to be about distinguishing, but if libpq
failed before even attempting a connection, PQNORESPONSE seems a bit
misleading.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2010-11-26 23:56:50 | Re: BUG #5773: DEBUG: reaping dead processes DEBUG: server process (PID 10007) was terminated by signal 11: Segme |
| Previous Message | Tom Lane | 2010-11-26 20:39:33 | Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-11-26 23:35:32 | Re: Assertion failure on hot standby |
| Previous Message | Bruce Momjian | 2010-11-26 23:16:11 | Re: duplicate connection failure messages |