Re: Multiple Xids in PGPROC?
От | Alvaro Herrera |
---|---|
Тема | Re: Multiple Xids in PGPROC? |
Дата | |
Msg-id | 20040505171452.GF22122@dcc.uchile.cl обсуждение исходный текст |
Ответ на | Re: Multiple Xids in PGPROC? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 = 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"
В списке pgsql-hackers по дате отправления: