From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [subxacts] Fixing TODO items |
Date: | 2004-07-28 06:31:22 |
Message-ID: | 20040728063122.GC17400@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
On Tue, Jul 27, 2004 at 01:32:01PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> > There are some likely controversial changes; the Xid caches, in the
> > first place.
>
> No kidding ;-)
>
> Do you have any theoretical or practical evidence for the usefulness of
> the negxids cache? Seems to me the shared memory space would be better
> spent on allowing deeper nesting of the running-subxids list. Also,
> what happened to marking whether the running-subxids list has
> overflowed? If none of them have then there's no need to wonder whether
> we have a still-running subxact.
Oh, sure, I had forgot about the overflow flag. I am working on that
now.
> The apparent lack of any locking on these data structures seems wrong
> too.
Well, storing the main Xid of a transaction in PGPROC is regarded as
"atomic" and it has no locking (other than SInvalLock in shared mode).
I think the correct solution would be to lock both the main Xid and the
XidCache with a per-backend LWLock, but you already rejected that idea.
My current patch uses SInvalLock in shared mode to protect reading and
writing the XidCaches. I am not sure this is a very good idea, but it
doesn't seem unreasonable either.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Et put se mouve" (Galileo Galilei)
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2004-07-28 06:54:47 | Re: USING INDEX TABLESPACE |
Previous Message | Joe Conway | 2004-07-28 04:38:34 | Re: casting strings to multidimensional arrays yields strange |