Re: Assertion failure on hot standby

On 26.11.2010 20:17, Robert Haas wrote:
> On Fri, Nov 26, 2010 at 10:53 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> If you have operation A in the master that currently acquires an
>> AccessExclusiveLock on a table, do you think it's safe for another
>> transaction to peek at the table at the same time?
>
> Beep, time out. The notion of "at the same time" is extremely fuzzy
> here. The operations on the master and slave are not simultaneous, or
> anything close to it.

In this context, "at the same time" means "at the same point in WAL".

>> As a concrete example, VACUUM acquires an AccessExclusiveLock when it wants
>> to truncate the relation. A sequential scan running against the table in the
>> standby will get upset, if the startup process replays a truncation record
>> on the table without warning.
>
> This case is similar. xl_smgr_truncate has only a relfilenode number,
> not a relation OID, so there's no way for the startup process to
> generate a conflicting lock request itself. But if the standby
> backends locked the relfilenode, or if the xl_smgr_truncate WAL record
> included the relation OID, it would be simple.

If you go down that path, you're going to spend a lot of time thinking
through every single case that uses an AccessExclusiveLock, ensuring
that the standby has enough information, and tinkering with the replay
code to acquire locks at the right moment. And gain what, exactly?

WAL-logging AccessExclusiveLocks is a bit ugly, but it beats having to
infer that information from other records hands down.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com