On Tuesday, March 12, 2013 9:37 PM Tom Lane wrote:
> Greg Stark <stark@mit.edu> writes:
> > 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.
>
> This would only be sane if we also postponed writing the file until
> commit. I don't know what is in the patch at the moment, but I
> remember
> that we had talked of executing the file write immediately when SET
> PERSISTENT is issued.
Currently the patch handles it by executing the file write immediately when
SET
PERSISTENT is issued.
You have pointed at that time it's better to write file immediately as if we
postpone
it to commit time, it can have some other complications.
The only doubt I have in doing pg_reload_conf() is about the point raised by
Fujii Masao yesterday,
that is it will load all other configurations apart from what had been
changed by SET PERSISTENT.
Are you okay with it, if we implement this and document such behavior
clearly?
With Regards,
Amit Kapila.
