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
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 |