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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers