From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Nested transactions: deferred triggers |
Date: | 2003-06-23 06:14:00 |
Message-ID: | 200306230614.h5N6E0U07482@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Alvaro Herrera wrote:
> On Wed, Jun 11, 2003 at 03:53:56PM -0400, Tom Lane wrote:
>
> > Seems reasonable, but I have a stylistic gripe:
> >
> > > + static DeferredTriggers ts;
> >
> > I dislike static variables with names as short as that --- they are too
> > likely to conflict against local variables. (And before you say there's
> > no problem because a local declaration would mask it, what happens if
> > you forget the local declaration?)
> >
> > I suspect you named it this way because you intend to pass it as a
> > parameter to all these routines later, and you're trying to avoid
> > one pass of editing when you add "DeferredTriggers ts" to the parameter
> > lists. I would suggest doing that now and including it in the patch.
> > Whether you are intending that or not, please use a better name for
> > the static variable.
>
> Actually, the function itself is going to obtain it via a
> TransactionGetDeferredTriggers() call so it's going to be a variable
> local to the function. I'm not sure if it can be made a parameter,
> because I don't control the deferred trigger queue completely (e.g. on
> new item insertion the caller is something outside my control).
>
> Please comment on what do you think about the
> TransactionGetDeferredTrigger function mentioned earlier. This is going
> to be in a struct that will be part of the TransactionState, and which
> will hold pointer to the deferred triggers queue, the smgr's pending
> deletes, the asynchronous notify queue and the OnCommit actions queue.
>
> Also there will be a MemoryContext for holding items on each of those
> lists. This context will be destroyed on subtransaction abort but will
> be kept on subtransaction commit -- this allows for easy deallocation of
> said items on subtrans abort, while keeping them after the
> subtransaction commits.
>
> So I need a way for the affected subsystems to get their structures.
> This is it. There'll also be a TransactionGetParentPendingDeletes so I
> can concatenate the list of the committing subtransaction to its
> parent's list. (This will be done using your new cool FastLists, BTW).
>
>
> Regarding the current patch, I have changed the variable name to
> something better. Please apply.
>
> Thanks for the quick reviewing.
>
> --
> Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
> "The Gord often wonders why people threaten never to come back after they've
> been told never to return" (www.actsofgord.com)
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
--
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 | 2003-06-23 06:15:48 | Re: Doc updates (minor) |
Previous Message | Bruce Momjian | 2003-06-23 06:09:26 | Re: perform.sgml update |