Re: Multiple Xids in PGPROC?

Alvaro Herrera <alvherre@dcc.uchile.cl>

From: Alvaro Herrera <alvherre@dcc.uchile.cl>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Hackers <pgsql-hackers@postgresql.org>
Date: 2004-05-05T17:14:52Z
Lists: pgsql-hackers
On Tue, May 04, 2004 at 11:21:07PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> > So, the big question is, how do we do this?  The most obvious way (to
> > me) is to keep the whole array inside the PGPROC struct.
> > ...
> > The main downside is that it potentially
> > requires a lot of shared memory.  Can we afford that?
> 
> No.  Shared memory is fixed size, therefore the above is guaranteed to
> fail.
> 
> I thought we had devised a solution that did not require expansible
> shared memory for this.  Bruce, Manfred, do you recall how that went?

All right, here is how I think it should work.

Consider the following scenario:

create table foo (a int);
BEGIN;					-- Xid = 100
	insert into foo values (1);
	BEGIN;				-- Xid = 110
		insert into foo values (2);
	COMMIT;
	
	BEGIN;				-- Xid = 120
		update foo set a=1;
	COMMIT;
COMMIT;

A backend starts just after Xid=120 has sub-committed.  Its snapshot
will be:

snapshot = {
	xmax = 150
	xmin = 90
	xip = { 100, ... }
}

So everytime I see a tuple with Xmin/Xmax between 90 and 150 I have to
look it up in pg_subtrans up to the topmost transaction (which will have
pg_subtrans=0) and see if the result is in the xip list.

For example, the tuple with Xid=110 will have pg_subtrans=100; Xid=100
will have pg_subtrans=0, and xip contains 100, so the tuple has xmin in
progress.

(I'd like to avoid the pg_subtrans lookup in the non-subtransaction case,
but I don't see how to do that.)

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"God is real, unless declared as int"