Re: Nested transactions: deferred triggers
| От | Bruce Momjian |
|---|---|
| Тема | Re: Nested transactions: deferred triggers |
| Дата | |
| Msg-id | 200306230614.h5N6E0U07482@candle.pha.pa.us обсуждение исходный текст |
| Ответ на | Re: Nested transactions: deferred triggers (Alvaro Herrera <alvherre@dcc.uchile.cl>) |
| Список | 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 по дате отправления: