Re: Multiple Xids in PGPROC?
От | Manfred Koizar |
---|---|
Тема | Re: Multiple Xids in PGPROC? |
Дата | |
Msg-id | o59i90dvkigbct9v69remkvnksfmobh6vf@email.aon.at обсуждение исходный текст |
Ответ на | Re: Multiple Xids in PGPROC? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Multiple Xids in PGPROC?
|
Список | pgsql-hackers |
On Tue, 04 May 2004 23:21:07 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote: >I thought we had devised a solution that did not require expansible >shared memory for this. Bruce, Manfred, do you recall how that went? AFAIR we did not discuss TransactionIdIsInProgress() specifically. Currently this function is special insofar as it does not consult pg_clog but loops over the PGPROC array. The current implementation is in sinval.c. The straightforward pg_clog lookup is still in transam.c, but has been deactivated:* Now this func in shmem.c and gives quality answer by scanning* PGPROC structures of all runningbackend. - vadim 11/26/96 What was the motivation for this change? Consistency or speed? With subtransactions we'd have to fall back to checking pg_clog (and pg_subtrans) in certain cases. There are lots of possible implementations. Here are some ideas (just brainstorming): . We could first scan the PGPROC array. If the xid is an active main transaction, we're finished. . If xid is older than RecentGlobalXmin, it cannot be active. . We could include a small number of subtransaction xids in PGPROC. . For additional subtransactions not fitting into this small array there could be minsubxid and maxsubxid fields in PGPROC. If the xid we are looking for is outside all these ranges, it cannot be an active subtransaction. . If all these tests fail, we fall back to checking pg_clog. ServusManfred
В списке pgsql-hackers по дате отправления: