On Tue, Mar 12, 2013 at 9:06 AM, Greg Smith <g...@2ndquadrant.com> wrote: > That's jumping right over a few rounds of simpler ways to do this, and just > going right to the approach we know allows adding more such options later > with minimal grammar impact.
As Craig intimated, the minimal grammar impact would be simply BEGIN; set persistent maintenance_work_mem='2GB'; set persistent work_mem='2GB'; COMMIT; Sending the sighup at transaction end seems like a fairly safe thing to do too. It's hard to imagine it failing and if it did the worst case would be that other backends would still have the old values too. To be honest I went through the gucs last night looking for a better example than this and didn't really find any compelling examples. The best I could come up with was adjusting several query costs in tandem. Hardly the end of the world if it didn't work. The worst case would be some security sensitive option alongside a second parameter for limiting its scope, but I couldn't find any such examples in a quick search. (And that's probably a good thing) -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
