[hackers-jp: 151] Fw: [HACKERS] Multiple Xids in PGPROC?

[TANIDA Yutaka]

谷田です。GWのメール、特にhackers多すぎ・・・

日本ではあまり話題になってないNested Transactionがらみの話です。（共有メ
モリ上に取られている）PGPROC構造体には今のところ１つのXID（現在実行され
ているトランザクションのID）が記録されているが、これがSub Transactionが
増えたときに複数どうやって取るか、あるいはここ以外にどこかで分かるように
するのか、と言う話のようです。少なくともいまの実装だと共有メモリを動的に
取るというのはできないし、頭の痛い話です。

Forwarded by TANIDA Yutaka <tanida ＠ sra.co.jp>
----------------------- Original Message -----------------------
 From:    Alvaro Herrera <alvherre ＠ dcc.uchile.cl>
 To:      Hackers <pgsql-hackers ＠ postgresql.org>
 Date:    Tue, 4 May 2004 22:32:09 -0400
 Subject: [HACKERS] Multiple Xids in PGPROC?
----

Hackers,

I've whacked the subtrans patch enough so that the simple tests (i.e.
non concurrent) for tuple visibility work.  I can create a table and
populate it in subtransactions, rollback or commit them selectively and
get the desired effect at the end.  Naturally, catalog entries also
behave [somewhat] sanely.  Oh, I made pg_subtrans work too.  (Though
whether it's relatively bug-free is yet to be proven.)

I'm now looking at changing the concurrent visibility rules, i.e.
utils/time/tqual.c.  It seems to me one of the most important parts is
making TransactionIdIsInProgress() behave, that is, yield true for every
committed and in-progress subtransaction of a current transaction tree.
(Not only the topmost Xid, which is what it currently does.)

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.  This would be
nice because it would only need little modification to
access/transam/varsup.c.  The main downside is that it potentially
requires a lot of shared memory.  Can we afford that?

I am already keeping the list of committed Xids in a backend-local list,
but of course this is not visible to other backends.

Does anyone have a better idea?  This is crucial.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Voy a acabar con todos los humanos / con los humanos yo acabari
voy a acabar con todos / con todos los humanos acabarñ(Bender)

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org


--------------------- Original Message Ends --------------------

-- 
TANIDA Yutaka <tanida ＠ sra.co.jp>