On Wed, Sep 12, 2018 at 09:48:04AM -0400, Bruce Momjian wrote:
> On Wed, Sep 12, 2018 at 11:27:44AM +0900, Michael Paquier wrote:
> > On Wed, Sep 12, 2018 at 06:51:44AM +0530, kalyani kaniganti wrote:
> > > I have a query,in our case old db is not getting shutdown cleanly .May I
> > > know why the DB is unable to shutdown cleanly and this happens repeatedly
> > > .How we can recover the cluster state going to in production state after
> > > stopping the cluster.
> >
> > If one of your PostgreSQL instances is not able to stop, its logs would
> > tell you what it did not have time to finish. You may perhaps blame the
> > time it takes for the shutdown checkpoint to finish. You should also
> > try to use the fast mode of "pg_ctl stop", which makes sure that all
> > sessions connected are forcibly finished cleanly, allowing Postgres to
> > not need crash recovery the next time it starts.
>
> Oh, I never suspected it was a timing issue. Use pg_ctl -w to wait for
> the shutdown. The default for wait has changed over time. I will add
> -w to the pg_upgrade manual page example using pg_ctl for stopping the
> server.
OK, so I looked into this and "wait/-w" has been the default action for
pg_ctl stop since at least PG 9.1, which is what the person was
reporting:
if (!wait_set)
{
switch (ctl_command)
{
case RESTART_COMMAND:
case START_COMMAND:
do_wait = false;
break;
case STOP_COMMAND:
do_wait = true;
break;
default:
break;
}
}
Are they using pg_ctl -W earlier? I don't know because the reporter is
not providing answers to my questions. I don't think it makes sense for
me to keep trying to guess the cause of this.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +