Re: Postgres 10.1 fails to start: server did not start in time

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Adam Brusselback <adambrusselback(at)gmail(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Postgres 10.1 fails to start: server did not start in time
Date: 2017-11-10 20:51:52
Message-ID: 8027.1510347112@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Adam Brusselback <adambrusselback(at)gmail(dot)com> writes:
> I am in the process of upgrading to Postgres 10, and am having trouble
> getting my streaming replica working.
> OS: Debian 9.2
> Version: 10.1
> I have my primary backed up using pgbackrest, and I restore that to my
> replica. It generates a recovery.conf which has a restore command for
> the WAL to pull them from the pgbackrest server.
> The recovery succeeds, but when I go to start the cluster on the
> standby, it begins to replay the WAL, and does so for about 30
> seconds. Then I get a line in my log saying:

>> pg_ctl: server did not start in time

You might want to increase pg_ctl's wait timeout for this situation,
since the default's evidently too little. However ...

> Followed by:
>> 2017-11-10 20:27:35.907 UTC [7132] LOG: received smart shutdown request
>> ERROR [063]: : terminated on signal [SIGTERM]

... pg_ctl itself wouldn't decide to forcibly shut down the server
if the timeout expired. It merely stops waiting and tells you so.
It seems like this must represent misdesign of whatever start script
you're using. I think you need to complain to the Debian packagers
about that.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adam Brusselback 2017-11-10 21:01:12 Re: Postgres 10.1 fails to start: server did not start in time
Previous Message Adam Brusselback 2017-11-10 20:32:18 Postgres 10.1 fails to start: server did not start in time