From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] Infrastructure changes for recovery (v8)
Date: Mon, 17 Nov 2008 16:18:39 +0200
Message-ID: <49217D3F.9050603@enterprisedb.com> (raw)
In-Reply-To: <1223472898.4747.310.camel@ebony.2ndQuadrant>
References: <1222815151.4445.1397.camel@ebony.2ndQuadrant>
<48EC9CC5.6060803@enterprisedb.com>
<1223468660.4747.294.camel@ebony.2ndQuadrant>
<1223472898.4747.310.camel@ebony.2ndQuadrant>
Simon Riggs wrote:
> @@ -3845,6 +3850,52 @@ sigusr1_handler(SIGNAL_ARGS)
>
> PG_SETMASK(&BlockSig);
>
> + if (CheckPostmasterSignal(PMSIGNAL_RECOVERY_START))
> + {
> + Assert(pmState == PM_STARTUP);
> +
> + /*
> + * Go to shutdown mode if a shutdown request was pending.
> + */
> + if (Shutdown > NoShutdown)
> + {
> + pmState = PM_WAIT_BACKENDS;
> + /* PostmasterStateMachine logic does the rest */
> + }
> + else
> + {
> + /*
> + * Startup process has entered recovery
> + */
> + pmState = PM_RECOVERY;
Hmm, I smell a race condition here:
1. Startup process goes into consistent state, and signals postmaster
2. Startup process finishes WAL replay and dies
3. Postmaster wakes up in reaper(), noting that the startup process
dies, and goes into PM_RUN mode.
4. The above signal handler for postmaster is run, causing an assertion
failure, or putting postmaster back into PM_RECOVERY mode if assertions
are disabled.
Highly unlikely in practice, given how much code needs to run in the
startup process between signaling the postmaster and exiting, but it
seems theoretically possible. Do we care, and if we do, how can we fix it?
> +
> + /*
> + * Load the flat authorization file into postmaster's ca
> + * startup process won't have recomputed this from the d
> + * yet, so it may change following recovery.
> + */
> + load_role();
Is there a race condition here too, if the startup process is writing
the auth file at the same time? I guess we'd have the same problem with
flat files in general, so maybe there's something else that mitigates
the problem?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: heikki.linnakangas@enterprisedb.com, simon@2ndQuadrant.com, pgsql-hackers@postgresql.org
Subject: Re: [PATCHES] Infrastructure changes for recovery (v8)
In-Reply-To: <49217D3F.9050603@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox