Re: Deadlock possibility in _bt_check_unique?

From: Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Deadlock possibility in _bt_check_unique?
Date: 2010-03-23 13:08:24
Message-ID: 9362e74e1003230608o6cd9006at60c9b3de3aa5f522@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Can you also explain how are we avoiding duplicates in this scenario?

a) Say there are three pages(P,Q, R) full of duplicate tuples, that are
deleted but not dead of id x(due to some long running transaction).
b) Now Session A gets in and checks the duplicate tuples for their
liveliness with the HeapTuple for id x with shared lock on all the pages P,
Q and R. Since all are deleted, it will get the message, that it need not
come back to check again for uniqueness Finally it again starts from P to
check for freespace to insert its tuple. Say it inserts the tuple at page Q.
c) Now Session B(with same id x) starts after Session A, but it passes Q
before the insertion of the tuple by Session A. It will also get the
response from _bt_check_unique, that it need not comeback for second time
unique check. Now it checks for freespace from P and it finds freespace at
P. Then it will insert the new record at P itself.

So we have two duplicate records, eventhough there is a unique constraint.
Is this a possible scenario?

Thanks,
Gokul.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hitoshi Harada 2010-03-23 14:01:35 Re: Windowing Qual Pushdown
Previous Message Heikki Linnakangas 2010-03-23 10:19:49 Re: Deadlock possibility in _bt_check_unique?