Re: Deadlock possibility in _bt_check_unique?

>
> Are you talking about exclusion constraints or btree uniqueness
> constraints? This doesn't seem to be a particularly accurate
> description of the implementation of either one. The way btree
> deals with this is explained in _bt_doinsert:
>

Unique constraints

>
> * NOTE: obviously, _bt_check_unique can only detect keys that are
> already
> * in the index; so it cannot defend against concurrent insertions of
> the
> * same key. We protect against that by means of holding a write lock
> on
> * the target page. Any other would-be inserter of the same key must
> * acquire a write lock on the same target page, so only one would-be
> * inserter can be making the check at one time. Furthermore, once we
> are
> * past the check we hold write locks continuously until we have
> performed
> * our insertion, so no later inserter can fail to see our insertion.
> * (This requires some care in _bt_insertonpg.)
>
>

This is fine, if the second session has to pass through the page, where the
first session inserted the record. But as i said if the second session finds
a free slot before hitting on the page where the first session inserted,
then it will never hit the page with write lock. The comment says that,

" Furthermore, once we are
* past the check we hold write locks continuously until we have
performed
* our insertion, so no later inserter can fail to see our insertion.
* (This requires some care in _bt_insertonpg.) "

But in the case, i suggested(page1, page2, page3 with non-dead duplicate
tuples, which are deleted), the first session checks page1, finds no
freespace, moves to page2, finds freespace and inserts. But when the second
session checks page1, say some of the tuples become dead. Then it gets
freespace there and inserts, but never sees the insertion of the first
session. Maybe, i am missing something. Just thought of raising the flag..

Gokul.