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. Cheers, Jeff
