| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <stark(at)mit(dot)edu> |
| Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] |
| Date: | 2013-03-12 16:07:16 |
| Message-ID: | 20482.1363104436@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <stark(at)mit(dot)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.
Maybe it's worth going in that direction just to cover the
multiple-updates case more conveniently.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | robins | 2013-03-12 16:35:05 | Add some regression tests for SEQUENCE |
| Previous Message | Heikki Linnakangas | 2013-03-12 16:03:50 | Re: Statistics and selectivity estimation for ranges |