From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Multiple Xids in PGPROC? |
Date: | 2004-05-05 18:02:55 |
Message-ID: | o59i90dvkigbct9v69remkvnksfmobh6vf@email.aon.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 04 May 2004 23:21:07 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>I thought we had devised a solution that did not require expansible
>shared memory for this. Bruce, Manfred, do you recall how that went?
AFAIR we did not discuss TransactionIdIsInProgress() specifically.
Currently this function is special insofar as it does not consult
pg_clog but loops over the PGPROC array. The current implementation is
in sinval.c. The straightforward pg_clog lookup is still in transam.c,
but has been deactivated:
* Now this func in shmem.c and gives quality answer by scanning
* PGPROC structures of all running backend. - vadim 11/26/96
What was the motivation for this change? Consistency or speed?
With subtransactions we'd have to fall back to checking pg_clog (and
pg_subtrans) in certain cases. There are lots of possible
implementations. Here are some ideas (just brainstorming):
. We could first scan the PGPROC array. If the xid is an active main
transaction, we're finished.
. If xid is older than RecentGlobalXmin, it cannot be active.
. We could include a small number of subtransaction xids in PGPROC.
. For additional subtransactions not fitting into this small array
there could be minsubxid and maxsubxid fields in PGPROC. If the xid we
are looking for is outside all these ranges, it cannot be an active
subtransaction.
. If all these tests fail, we fall back to checking pg_clog.
Servus
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2004-05-05 18:06:53 | Re: PostgreSQL pre-fork speedup |
Previous Message | Tom Lane | 2004-05-05 17:59:04 | Re: ALTER TABLE TODO items |