Re: Deadlock possibility in _bt_check_unique? - Mailing list pgsql-hackers

From Gokulakannan Somasundaram
Subject Re: Deadlock possibility in _bt_check_unique?
Date
Msg-id 9362e74e1003230608o6cd9006at60c9b3de3aa5f522@mail.gmail.com
Whole thread Raw
In response to Re: Deadlock possibility in _bt_check_unique?  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Deadlock possibility in _bt_check_unique?
List pgsql-hackers
Can you also explain how are we avoiding duplicates in this scenario?<br /><br />a) Say there are three pages(P,Q, R)
fullof duplicate tuples, that are deleted but not dead of id x(due to some long running transaction).<br />b) Now
SessionA gets in and checks the duplicate tuples for their liveliness with the HeapTuple for id x with shared lock on
allthe pages P, Q and R. Since all are deleted, it will get the message, that it need not come back to check again for
uniquenessFinally it again starts from P to check for freespace to insert its tuple. Say it inserts the tuple at page
Q.<br/> c) Now Session B(with same id x) starts after Session A, but it passes Q before the insertion of the tuple by
SessionA. It will also get the response from _bt_check_unique, that it need not comeback for second time unique check.
Nowit checks for freespace from P and it finds freespace at P. Then it will insert the new record at P itself.<br /><br
/>Sowe have two duplicate records, eventhough there is a unique constraint. Is this a possible scenario?<br /><br
/>Thanks,<br/>Gokul.<br /><br /><br /> 

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Deadlock possibility in _bt_check_unique?
Next
From: Hitoshi Harada
Date:
Subject: Re: Windowing Qual Pushdown