Re: HS locking broken in HEAD

On 2013-01-17 22:46:21 +0100, Andres Freund wrote:
> Hi,
>
>
> While checking whether I could reproduce the replication delay reported
> by Michael Paquier I found this very nice tidbit:
>
> In a pretty trivial replication setup of only streaming replication I
> can currently easily reproduce this:
>
> standby# BEGIN;SELECT * FROM foo;
> BEGIN
> id | data
> ----+------
>
>
> standby=# SELECT relation::regclass, locktype, mode FROM pg_locks;
> relation | locktype | mode
> ----------+------------+-----------------
> pg_locks | relation | AccessShareLock
> foo_pkey | relation | AccessShareLock
> foo | relation | AccessShareLock
> | virtualxid | ExclusiveLock
> | virtualxid | ExclusiveLock
> (5 rows)
>
> primary# DROP TABLE foo;
> DROP TABLE
>
>
> standby# SELECT relation::regclass, pid, locktype, mode FROM pg_locks;
> relation | pid | locktype | mode
> ----------+-------+------------+---------------------
> pg_locks | 28068 | relation | AccessShareLock
> foo_pkey | 28068 | relation | AccessShareLock
> foo | 28068 | relation | AccessShareLock
> | 28068 | virtualxid | ExclusiveLock
> | 28048 | virtualxid | ExclusiveLock
> foo | 28048 | relation | AccessExclusiveLock
> (6 rows)
>
> standby# SELECT * FROM foo;
> ERROR: relation "foo" does not exist
> LINE 1: select * from foo;
> ^
> Note the conflicting locks held on relation foo by 28048 and 28068.
>
> I don't immediately know which patch to blame here? Looks a bit like
> broken fastpath locking, but I don't immediately see anything in
> c00dc337b87 that should cause this?

Rather scarily this got broken in
96cc18eef6489cccefe351baa193f32f12018551. Yes, nearly half a year ago,
including in 9.2.1+. How the heck could this go unnoticed so long?

Not sure yet what the cause of this is.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services