Re: Re: Clarifying "server starting" messaging in pg_ctl start without --wait

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Ryan Murphy <ryanfmurphy(at)gmail(dot)com>, Beena Emerson <memissemerson(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Clarifying "server starting" messaging in pg_ctl start without --wait
Date: 2017-01-18 20:59:01
Message-ID: 20170118205901.GF18360@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Wed, Jan 18, 2017 at 3:43 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> >> I think we've changed the defaults to make things better for an
> >> attended startup and worse for an unattended startup. But I think
> >> most PostgreSQL startups are probably unattended.
> >
> > I don't understand how it's worse for an unattended startup to tell the
> > init system that the database is now up and running when, in fact, it
> > isn't.
> >
> > If that isn't what you meant, then it would be really helpful if you
> > could explain a bit more what you see as being "worse" with this change
> > for unattended startup.
>
> This seems clear as day to me, so I'm not sure what to explain.
> Anybody who has got a script that runs pg_ctl unattended mode likely
> now has to go update that script to add --no-wait. If they don't,
> their script may hang for whatever the timeout is (currently 60
> seconds, and it sounds like Peter wants to change that to infiniity).
> If they have been wanting their script to hang all along, as you seem
> to be saying, then they'll be happy that it now does. If, on the
> other hand, they don't want that, then they'll be sad.

Ok, you're talking about for the cold standby case here, correct? If
so, then I agree that we should work a bit harder to make pg_ctl realize
that configuration and have it not wait for the entire timeout in that
specific situation.

That said, I, honestly, don't remember the last time I ran into a cold
standby configuration.

For non-cold standby configurations, pg_ctl is going to return just as
soon as the database has finished crash recovery, which in most cases
will probably be on the order of a few seconds. Note that pg_ctl
retries connecting every second, it doesn't just hang and do nothing
until the timeout.

For any case where the user is actually calling pg_ctl to start the
database so that they can make connections to the database and to use it
for something, which seems much more likely, this change will mean that
they can remove the random 'sleep' they stuck in their script that they
added when they discovered that pg_ctl wasn't waiting for the database
to actually be online before returning. Or the '--wait' they already
put in there will now be unnecessary, but that's not going to hurt
anything. Or the loop they put in to keep trying to connect until the
database is actually up.

> In short, I bet we will get multiple reports of people getting hosed
> by this change.

I would be very surprised if we got any reports of people being hosed by
this change, but I do think we should mention it in the release notes.

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2017-01-18 21:08:07 Re: patch: function xmltable
Previous Message Robert Haas 2017-01-18 20:52:36 Re: Patch to implement pg_current_logfile() function