From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Multiple Xids in PGPROC? |
Date: | 2004-05-05 12:20:11 |
Message-ID: | 20040505122011.GA20978@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 04, 2004 at 11:21:18PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > 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 remember going through this. Other backends will use pg_subtrans to
> know what transactions are in progress. They have to do the standard
> lookups to find the status of the parent transaction. The backend-local
> list of xids is needed so the commit can clean up those subtransaction
> xids so that later transactions don't have to use pg_subtrans.
Ok, this can be done with what I have so far. I'm not sure how slow
will it be compared to checking the PGPROC struct, because it may
involve getting a pg_subtrans page from disk. Currently I have 8
pg_subtrans buffers on shared memory, the same as pg_clog; maybe we want
more to reduce that probability. 8 kB each, 2k xacts each, 16k xacts
total.
I'll test this and will probably be submitting a patch shortly.
> Sorry I haven't gotten your patches in yet. Tom is working on some
> other back patches.
I've been sloppy lately with #ifdef, because it takes some time to get
right and testing it takes even more time. I don't know if it's worth
it -- do you still have the idea of incremental, non disturbing patches?
> Also, do you have a plan to handle some of the more complex issues
> like locking in subtransactions?
Certainly. As soon as I have a concurrent scenario working, I'll pursue
the cleanup of all modules at subxact abort. (I have some working, some
which I know don't work, and some which I haven't tried yet.)
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Cada quien es cada cual y baja las escaleras como quiere" (JMSerrat)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-05-05 13:55:35 | Re: [PATCHES] Function to do runtime relative directory |
Previous Message | Peter Galbavy | 2004-05-05 10:29:55 | Re: PostgreSQL pre-fork speedup |