Re: Multiple Xids in PGPROC?

On Tue, May 04, 2004 at 11:21:07PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)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"