HS locking broken in HEAD

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;
BEGINid | data 
----+------


standby=# SELECT relation::regclass, locktype, mode FROM pg_locks;relation |  locktype  |      mode       
----------+------------+-----------------pg_locks | relation   | AccessShareLockfoo_pkey | relation   |
AccessShareLockfoo     | 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   | AccessShareLockfoo_pkey | 28068 |
relation  | AccessShareLockfoo      | 28068 | relation   | AccessShareLock         | 28068 | virtualxid | ExclusiveLock
       | 28048 | virtualxid | ExclusiveLockfoo      | 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?

Greetings,

Andres Freund

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