Horton
Menu

Re: max_standby_delay considered harmful

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Florian Pflug <fgp@phlo.org>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Andres Freund <andres@anarazel.de>, Dimitri Fontaine <dfontaine@hi-media.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org, Bruce Momjian <bruce@momjian.us>, Greg Smith <greg@2ndquadrant.com>, Simon Riggs <simon@2ndquadrant.com>
Date: 2010-05-10T11:57:23Z
Lists: pgsql-hackers 
On Mon, May 10, 2010 at 6:13 AM, Florian Pflug <fgp@phlo.org> wrote:
> On May 10, 2010, at 11:43 , Heikki Linnakangas wrote:
>> If you're not going to apply any more WAL records before shutdown, you
>> could also just release all the AccessExclusiveLocks held by the startup
>> process. Whatever the transaction was doing with the locked relation, if
>> we're not going to replay any more WAL records before shutdown, we will
>> not see the transaction committing or doing anything else with the
>> relation, so we should be safe. Whatever state the data on disk is in,
>> it must be valid, or we would have a problem with crash recovery
>> recovering up to this WAL record and then starting up too.
>
> Sounds plausible. But wouldn't this imply that HS could *always* postpone the acquisition of an AccessExclusiveLocks until right before the corresponding commit record is replayed? If fail to see a case where this would fail, yet recovery in case of an intermediate crash would be correct.

Yeah, I'd like to understand this, too.  I don't have a clear
understanding of when HS needs to take locks here in the first place.

[removing Josh Berkus's persistently bouncing email from the CC line]

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company