From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hot standby, recovery infra |
Date: | 2009-02-06 08:06:15 |
Message-ID: | 498BEF77.2070100@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs wrote:
> On Thu, 2009-02-05 at 21:54 +0200, Heikki Linnakangas wrote:
>> - If you perform a fast shutdown while startup process is waiting for
>> the restore command, startup process sometimes throws a FATAL error
>> which leads escalates into an immediate shutdown. That leads to
>> different messages in the logs, and skipping of the shutdown
>> restartpoint that we now otherwise perform.
>
> Sometimes?
I think what happens is that if the restore command receives the SIGTERM
and dies before the startup process that's waiting for the restore
command receives the SIGTERM, the startup process throws a FATAL error
because the restore command died unexpectedly. I put this
> if (shutdown_requested && InRedo)
> {
> /* XXX: Is EndRecPtr always the right value here? */
> UpdateMinRecoveryPoint(EndRecPtr);
> proc_exit(0);
> }
right after the "system(xlogRestoreCmd)" call, to exit gracefully if we
were requested to shut down while restore command was running, but it
seems that that's not enough because of the race condition.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2009-02-06 08:17:14 | Re: Hot standby, recovery infra |
Previous Message | Simon Riggs | 2009-02-06 07:59:47 | Re: new GUC var: autovacuum_process_all_tables |