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;
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?

Greetings,

Andres Freund

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