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: