Hi,
With the implementation of deferred unique constraints, we need to go
back to the index second time to check whether the unique check is valid.
Say a situation occurs like this
a) the first session doing the unique check finds out that there is a unique
check required second time and just
Gokulakannan Somasundaram wrote:
Hi,
With the implementation of deferred unique constraints, we need to go
back to the index second time to check whether the unique check is valid.
Say a situation occurs like this
a) the first session doing the unique check finds out that there is a unique
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
Gokulakannan Somasundaram gokul...@gmail.com writes:
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
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,
Gokulakannan Somasundaram gokul...@gmail.com writes:
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
No, you don't understand how it works. All would-be inserters will hit
the same target page to begin with, ie, the first one that the new key
could legally be inserted on. The lock that protects against this
problem is the lock on that page, regardless of which page the key
actually ends up
Gokulakannan Somasundaram gokul...@gmail.com writes:
Consider Time instances T1, T2, T3, T4
T1 : session 1 holds the write lock on page p1 and completes the unique
check on p1, p2 and p3.
T2 : session 1 releases the lock on p1 (its waiting to acquire a ex lock on
p2)
That's not what we do.
T2 : session 1 releases the lock on p1 (its waiting to acquire a ex lock
on
p2)
That's not what we do. See _bt_findinsertloc.
regards, tom lane
I am really confused. Please keep the cool and explain me, if i am
wrong. I could see this code in
Oh! yeah, i got it. Thanks
On Wed, Mar 24, 2010 at 12:26 AM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
T2 : session 1 releases the lock on p1 (its waiting to acquire a ex lock
on
p2)
That's not what we do. See _bt_findinsertloc.
regards, tom lane
Gokulakannan Somasundaram gokul...@gmail.com writes:
I am really confused. Please keep the cool and explain me, if i am
wrong. I could see this code in _bt_findinsertloc. There is a
_bt_relandgetbuf, which releases lock on p1 and tries to acquire a lock on
p2.
No, read it again. The
11 matches
Mail list logo
