Alvaro Herrera wrote: > On Fri, May 28, 2004 at 11:11:27PM -0400, Bruce Momjian wrote: > > Alvaro Herrera wrote: > > > > I think this applies to all GUC variables, but I wonder if we want to > > > save the value of each one at subtransaction start and recover it at > > > abort? Things could easily get huge. Maybe only saving the ones that > > > are different from the default value, and from the last saved value. > > > > We have an on-commit field in the guc structures to handle > > commit/rollback settings. Do we need to extend that to subtransactions? > > Yes IMHO. I'm not sure actually _how_ should this be handled. Maybe > the on-commit field should go away and be replaced by something more > general (probably a stack, like everything else). Let me look at the > code. > > > I don't think you can save off only the defaults in an efficient manner. > > What do you mean by efficient? Space efficient? It will be much more > efficient to save only the changed values. Time efficient? We will > have to traverse the whole list anyway, whether we only save the changed > values or all of them. > > Remember, we already traverse the whole list of shared buffers, the > whole CatCache, the whole Relcache, maybe do some repallocs, and lots of > other stuff. Traversing the whole GUC array does not seem all that > expensive to me ... After all, we are saving lots of I/O if subxacts > are used correctly (try, rollback, try again -- you save the XLog for > the first try.)
My comment was based on the fact that guc already does some special _saves_ when you change a value and triggers some stuff on xact end. I was just thinking it would be cleaner to use that infrastructure rather than do a scan not knowing if any GUC will change or not, but if a scan is easier, I think that would be fine. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
