Re: Review: Hot standby
От | Simon Riggs |
---|---|
Тема | Re: Review: Hot standby |
Дата | |
Msg-id | 1227274535.7015.80.camel@hp_dx2400_1 обсуждение исходный текст |
Ответ на | Re: Review: Hot standby ("Pavan Deolasee" <pavan.deolasee@gmail.com>) |
Список | pgsql-hackers |
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.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: