Re: Review: Hot standby - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Review: Hot standby
Date
Msg-id 2e78013d0811210151i1ef5909fqad475489a049bdd4@mail.gmail.com
Whole thread Raw
In response to Re: Review: Hot standby  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Responses Re: Review: Hot standby  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
<br />+       /*<br />+        * Release locks, if any.<br />+        */<br />+      
RelationReleaseRecoveryLocks(xlrec->slotId);<br/><br /><br />If I am reading the patch correctly,
AccessExclusiveLocksacquired by a transaction will be released when the transaction is committed or aborted. If the
transactionerrors out with FATAL, the locks will be released when the next transaction occupying the same slot is
committed/aborted.<brclear="all" /><br />I smell some sort of deadlock condition here. What if the following events
happen:<br/><br />- transaction A (slot 1) starts and acquires AEL lock on relation<br />- transaction A errors out
with FATAL error<br />- transaction B (slot 1) starts and requests AEL lock on the same relation<br /><br />Won't B
deadlockwith A ? Since B hasn't yet committed/aborted, the lock held by A is not released and <br
/>relation_redo_lock()would indefinitely wait for the lock.<br /><br />Thanks,<br />Pavan<br /><br />-- <br />Pavan
Deolasee<br/> EnterpriseDB     <a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br /> 

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Should enum GUCs be listed as such in config.sgml?
Next
From: KaiGai Kohei
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)