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 = 100insert 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 = 150xmin = 90xip = { 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"
