From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | Matthias Kurz <m(dot)kurz(at)irregular(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add read-only param to set_config(...) / SET that effects (at least) customized runtime options |
Date: | 2018-04-20 20:18:10 |
Message-ID: | 358a360a-f56b-f826-50f4-f9d89deddc70@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04/20/2018 04:03 PM, Andrew Gierth wrote:
>>>>>> "Chapman" == Chapman Flack <chap(at)anastigmatix(dot)net> writes:
> Chapman> It seemed to me at the time to be not hard to implement, even
> Chapman> just as an extension for proof of concept. One small obstacle
> Chapman> is that the check hook on a variable doesn't get called during
> Chapman> attempted RESET, so the only way to block a prohibited RESET
> Chapman> would have to be from an assign hook, which isn't expected to
> Chapman> fail. It could surely throw an error, but which would mess up
> Chapman> the whole RESET, but might be tolerable.
>
> Assign hooks aren't allowed to throw errors under any circumstance
> because they're called during transaction abort, and throwing an error
> during abort is obviously not tolerable.
Ah yes, now you remind me, that was why I had put my extension idea
on the table at the time.
It seems as if, for any of these ideas (cookie-protection of GUCs
or just SET READONLY for GUCs), at least some small patch to core
will be prerequisite, to allow either a flag or a reset check hook
able to make RESET skip protected GUCs.
-Chap
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2018-04-20 20:49:08 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
Previous Message | Peter Geoghegan | 2018-04-20 20:06:15 | Re: Corrupted btree index on HEAD because of covering indexes |