Re: is_superuser versus set_config_option's parallelism check
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org, Robert Haas <robertmhaas@gmail.com>
Date: 2024-08-10T14:26:38Z
Lists: pgsql-hackers
On Fri, Aug 09, 2024 at 06:50:14PM -0400, Tom Lane wrote: > Here's a draft patch to fix it with a flag, now with regression tests. Looks reasonable. > Also, now that the error depends on which parameter we're talking > about, I thought it best to include the parameter name in the error > and to re-word it to be more like all the other can't-set-this-now > errors just below it. I'm half tempted to change the errcode and > set_config_option return value to match the others too, ie > ERRCODE_CANT_CHANGE_RUNTIME_PARAM and "return 0" not -1. > I don't think the existing choices here are very well thought > through, and they're certainly inconsistent with a lot of > otherwise-similar-seeming refusals in set_config_option. This comment for set_config_option() leads me to think we should be returning -1 instead of 0 in many more places in set_config_with_handle(): * Return value: * +1: the value is valid and was successfully applied. * 0: the name or value is invalid (but see below). * -1: the value was not applied because of context, priority, or changeVal. But I haven't thought through it, either. At this point, maybe the comment is wrong... -- nathan
Commits
-
Allow adjusting session_authorization and role in parallel workers.
- 364de74cff28 18.0 landed
- f3ab5d3a2d19 16.5 landed
- adf9808fa966 13.17 landed
- adc28d01e98b 12.21 landed
- 546a26b3d8df 14.14 landed
- 2f4e895be760 15.9 landed
- 2b8d33f66c13 17.0 landed
-
Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings view.
- 059de3ca4766 17.0 cited