| From: | Decibel! <decibel(at)decibel(dot)org> | 
|---|---|
| To: | Luca Ferrari <fluca1978(at)infinito(dot)it> | 
| Cc: | pgsql-novice(at)postgresql(dot)org | 
| Subject: | Re: buffer page lock vs tuple lock (?) | 
| Date: | 2007-08-08 22:20:21 | 
| Message-ID: | 20070808222021.GC20424@nasby.net | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-novice | 
On Tue, Aug 07, 2007 at 09:52:40AM +0200, Luca Ferrari wrote:
> Hi,
> if I get it right a heap buffer page (that contains several tuples) requires a 
> pin and a lock to access the page content, and a change to a tuple requires a 
> lock on the tuple too. Disregarding some cases (tuple shuffling within the 
> same page and vacuum) does not this double locking be too much? I mean, does 
> not suffice to pin the page and lock the tuple (e.g., reading)?
> Can anybody help me understanding?
There's two different types of locking involved here. The page locking
mechanism is strictly internal-only, and is used only to ensure that
data on a page can't be corrupted by concurrent operations. But there's
a number of operations that can modify a page, many of which will never
acquire any row locks.
Row locks OTOH are used for transaction isolation. The two concepts are
actually separate.
-- 
Decibel!, aka Jim Nasby                        decibel(at)decibel(dot)org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oliver Elphick | 2007-08-10 05:44:15 | Re: restoring with sql script | 
| Previous Message | Demian Quinonez | 2007-08-08 22:17:44 | restoring with sql script |