Re: Multiple Xids in PGPROC? - Mailing list pgsql-hackers

From Manfred Koizar
Subject Re: Multiple Xids in PGPROC?
Date
Msg-id o59i90dvkigbct9v69remkvnksfmobh6vf@email.aon.at
Whole thread Raw
In response to Re: Multiple Xids in PGPROC?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Multiple Xids in PGPROC?
List pgsql-hackers
On Tue, 04 May 2004 23:21:07 -0400, Tom Lane <tgl@sss.pgh.pa.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
runningbackend. - 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.

ServusManfred


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Postgres Crashes
Next
From: Tom Lane
Date:
Subject: Re: ALTER TABLE TODO items