On Tue, May 04, 2004 at 11:21:07PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> 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"
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
