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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
