Re: Nested transactions: deferred triggers - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: Nested transactions: deferred triggers
Date
Msg-id 200306230614.h5N6E0U07482@candle.pha.pa.us
Whole thread Raw
In response to Re: Nested transactions: deferred triggers  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List 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@postgresql.org so that your
> message can get through to the mailing list cleanly

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] MARKED_FOR_UPDATE && XMAX_COMMITTED == XMAX_INVALID ?
Next
From: Bruce Momjian
Date:
Subject: Re: Doc updates (minor)