| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gokulakannan Somasundaram <gokul007(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Deadlock possibility in _bt_check_unique? |
| Date: | 2010-03-23 17:49:55 |
| Message-ID: | 3384.1269366595@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Gokulakannan Somasundaram <gokul007(at)gmail(dot)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 never hit the page with write lock. The comment says that,
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 on.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gokulakannan Somasundaram | 2010-03-23 18:06:41 | Re: Deadlock possibility in _bt_check_unique? |
| Previous Message | Gokulakannan Somasundaram | 2010-03-23 17:43:06 | Re: Deadlock possibility in _bt_check_unique? |