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
