From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Nested xacts: looking for testers and review |
Date: | 2004-05-29 03:11:27 |
Message-ID: | 200405290311.i4T3BRp14904@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera wrote:
> On Fri, May 28, 2004 at 05:43:41PM -0700, Stephan Szabo wrote:
>
> > On Wed, 26 May 2004, Alvaro Herrera wrote:
> >
> > > I have tested it and it passes all regression tests (including ones I
> > > added), plus some more tests I threw at it mainly for concurrency.
> > > Everything behaves as expected. At this time I'd like to have it
> > > reviewed by the critic eye of the committers, and tested by whoever
> > > would be using it.
> >
> > I unfortunately didn't really follow the discussions in the past (sorry :(
> > ), but are the transaction state modifying statements done in a
> > subtransaction supposed to live beyond subtransaction rollback?
>
> Hmm, I suppose not.
>
> I think this applies to all GUC variables, but I wonder if we want to
> save the value of each one at subtransaction start and recover it at
> abort? Things could easily get huge. Maybe only saving the ones that
> are different from the default value, and from the last saved value.
We have an on-commit field in the guc structures to handle
commit/rollback settings. Do we need to extend that to subtransactions?
I don't think you can save off only the defaults in an efficient manner.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-05-29 03:19:42 | Re: temp tables broken in CVS HEAD? |
Previous Message | Alvaro Herrera | 2004-05-29 01:59:53 | Re: SELECT * FROM <table> LIMIT 1; is really slow |