On 2013-01-17 23:56:16 +0100, Andres Freund wrote:
> On 2013-01-17 22:46:21 +0100, Andres Freund wrote:
^
> > 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?
That only made the bug more visible - the real bug is somewhere
else. Which makes it even scarrier, the bug was in in the fast path
locking patch from the start...
It assumes conflicting fast path locks can only ever be in the same
database as the the backend transfering the locks to itself. But thats
obviously not true for the startup process which is in no specific
database.
I think it might also be a dangerous assumption for shared objects?
A patch minimally addressing the is attached, but it only addresses part
of the problem.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index f2cf5c6..b5240da 100644
--- a/src/backend/storage/lmgr/lock.c
+++ b/src/backend/storage/lmgr/lock.c
@@ -2458,8 +2458,13 @@ FastPathTransferRelationLocks(LockMethod lockMethodTable, const LOCKTAG *locktag
* less clear that our backend is certain to have performed a memory
* fencing operation since the other backend set proc->databaseId. So
* for now, we test it after acquiring the LWLock just to be safe.
+ *
+ * But if we are the startup process we don't belong to a database but
+ * still need to lock objects in other databases, so we can do this
+ * optimization only in case we belong to a database.
+ * XXX: explain why this is safe for shared tables.
*/
- if (proc->databaseId != MyDatabaseId)
+ if (MyDatabaseId != InvalidOid && proc->databaseId != MyDatabaseId)
{
LWLockRelease(proc->backendLock);
continue;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
