On Tue, Mar 12, 2013 at 11:36 AM, Greg Stark <stark@mit.edu> wrote:
> On Tue, Mar 12, 2013 at 9:06 AM, Greg Smith <greg@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.
I'm late to the party here, but my feeling is that we ought NOT to
send a SIGHUP automatically. For various reasons already discussed,
that's not going to be completely transparent to the DBA. And when
things are not fully transparent, IME, it's better not to do them
automatically. DBAs like automation when it's 100% reliable - but
they don't like the database to automatically do things that can have
unforeseen side effects.
Also, while I think that MOST people will probably want a SIGHUP right
after SET PERSISTENT, I am not sure that EVERYONE will want that. If
you want it and it doesn't happen automatically, you can always do it
by hand. If you don't want it and it does happen automatically,
you're out of luck: go back to hand-editing config files. I really
don't want to leave people with any more reasons to continue
hand-editing the config files than we truly must.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
