| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | letizia leo <letizia_leo(at)yahoo(dot)it> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Rome university |
| Date: | 2006-05-02 21:48:37 |
| Message-ID: | 20060502214837.GB18026@surnet.cl |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
letizia leo wrote:
> and the doubt is the following: how is it possible that -line 144- Xmin
> is the current transaction ( i.e. it has created this tuple, it is
> holding an exclusive lock on it since it has not committed yet) and
> that
> -line 149- there is a different (?) transaction that is also locking
> the
> tuple (HEAP_IS_LOCKED=(HEAP_XMAX_EXCL_LOCK||HEAP_XMAX_SHARED_LOCK) )?
> Unless we are missing something, this situation is possible exclusively
> in case the XMAX transaction is a subtransaction of XMIN, which can
> access the tuple despite the exclusive lock held by XMIN.
Exactly.
> This seems correct according to the comment in line 154, which refers
> to a "subtransaction".
It is correct.
> Are we understanding correctly what this code is doing and the related
> underlying MVCC mechanisms?
Can't say, but that part at least you got right :-)
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martijn van Oosterhout | 2006-05-02 22:00:38 | Re: Rome university |
| Previous Message | Martijn van Oosterhout | 2006-05-02 19:19:22 | Re: patch review, please: Autovacuum/Vacuum times via stats. |