On June 29, 2017 10:19:46 AM PDT, Jeff Janes <jeff.ja...@gmail.com> wrote: >On Tue, Jun 27, 2017 at 11:59 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> I wrote: >> > Andres Freund <and...@anarazel.de> writes: >> >> On 2017-06-26 17:38:03 -0400, Tom Lane wrote: >> >>> Hm. Take that a bit further, and we could drop the connection >probes >> >>> altogether --- just put the whole responsibility on the >postmaster to >> >>> show in the pidfile whether it's ready for connections or not. >> >> >> Yea, that seems quite appealing, both from an architectural, >simplicity, >> >> and log noise perspective. I wonder if there's some added >reliability by >> >> the connection probe though? Essentially wondering if it'd be >worthwhile >> >> to keep a single connection test at the end. I'm somewhat >disinclined >> >> though. >> >> > I agree --- part of the appeal of this idea is that there could be >a net >> > subtraction of code from pg_ctl. (I think it wouldn't have to link >libpq >> > anymore at all, though maybe I forgot something.) And you get rid >of a >> > bunch of can't-connect failure modes, eg kernel packet filter in >the way, >> > which probably outweighs any hypothetical reliability gain from >> confirming >> > the postmaster state the old way. >> >> Here's a draft patch for that. I quite like the results --- this >seems >> way simpler and more reliable than what pg_ctl has done up to now. >> However, it's certainly arguable that this is too much change for an >> optional post-beta patch. > > >In the now-committed version of this, the 'pg_ctl start' returns >successfully as soon as the server reaches a consistent state. Which is >OK, >except that it does the same thing when hot_standby=off. When >hot_standby=off, I would expect it to wait for the end of recovery >before >exiting with a success code.
I've not looked at the committed version, but earlier versions had code dealing with that difference; essentially doing what you suggest. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers