On Fri, 2008-11-21 at 15:21 +0530, Pavan Deolasee wrote: > > + /* > + * Release locks, if any. > + */ > + RelationReleaseRecoveryLocks(xlrec->slotId); > > > If I am reading the patch correctly, AccessExclusiveLocks acquired by > a transaction will be released when the transaction is committed or > aborted. If the transaction errors out with FATAL, the locks will be > released when the next transaction occupying the same slot is > committed/aborted. > > I smell some sort of deadlock condition here. What if the following > events happen: > > - transaction A (slot 1) starts and acquires AEL lock on relation > - transaction A errors out with FATAL error > - transaction B (slot 1) starts and requests AEL lock on the same > relation > > Won't B deadlock with A ? Since B hasn't yet committed/aborted, the > lock held by A is not released and > relation_redo_lock() would indefinitely wait for the lock.
This won't happen because the lock is held by the startup process on behalf of slot 1. Explained in comments in inval.c code. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
