Re: Nested transactions: deferred triggers

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

In response to

Browse pgsql-patches by date

  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