pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings @ 2023-12-26 22:58 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-26 22:58 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings view. set_config_option() bails out early if it detects that the option to be set is PGC_BACKEND or PGC_SU_BACKEND class and we're reading the config file in a postmaster child; we don't want to apply any new value in such a case. That's fine as far as it goes, but it fails to consider the requirements of the pg_file_settings view: for that, we need to check validity of the value even though we have no intention to apply it. Because we didn't, even very silly values for affected GUCs would be reported as valid by the view. There are only half a dozen such GUCs, which perhaps explains why this got overlooked for so long. Fix by continuing when changeVal is false; this parallels the logic in some other early-exit paths. Also, the check added by commit 924bcf4f1 to prevent GUC changes in parallel workers seems a few bricks shy of a load: it's evidently assuming that ereport(elevel, ...) won't return. Make sure we bail out if it does. The lack of trouble reports suggests that this is only a latent bug, i.e. parallel workers don't actually reach here with elevel < ERROR. (Per the code coverage report, we never reach here at all in the regression suite.) But we clearly don't want to risk proceeding if that does happen. Per report from Rıdvan Korkmaz. These are ancient bugs, so back-patch to all supported branches. Discussion: https://postgr.es/m/2089235.1703617353@sss.pgh.pa.us Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/bf4f30a0fadafa76127522a4bbefaed2b1c71493 Modified Files -------------- src/backend/utils/misc/guc.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings @ 2023-12-26 22:58 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-26 22:58 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings view. set_config_option() bails out early if it detects that the option to be set is PGC_BACKEND or PGC_SU_BACKEND class and we're reading the config file in a postmaster child; we don't want to apply any new value in such a case. That's fine as far as it goes, but it fails to consider the requirements of the pg_file_settings view: for that, we need to check validity of the value even though we have no intention to apply it. Because we didn't, even very silly values for affected GUCs would be reported as valid by the view. There are only half a dozen such GUCs, which perhaps explains why this got overlooked for so long. Fix by continuing when changeVal is false; this parallels the logic in some other early-exit paths. Also, the check added by commit 924bcf4f1 to prevent GUC changes in parallel workers seems a few bricks shy of a load: it's evidently assuming that ereport(elevel, ...) won't return. Make sure we bail out if it does. The lack of trouble reports suggests that this is only a latent bug, i.e. parallel workers don't actually reach here with elevel < ERROR. (Per the code coverage report, we never reach here at all in the regression suite.) But we clearly don't want to risk proceeding if that does happen. Per report from Rıdvan Korkmaz. These are ancient bugs, so back-patch to all supported branches. Discussion: https://postgr.es/m/2089235.1703617353@sss.pgh.pa.us Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/059de3ca4766012743b4ff7c8e7193abb71f7189 Modified Files -------------- src/backend/utils/misc/guc.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings @ 2023-12-26 22:58 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-26 22:58 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings view. set_config_option() bails out early if it detects that the option to be set is PGC_BACKEND or PGC_SU_BACKEND class and we're reading the config file in a postmaster child; we don't want to apply any new value in such a case. That's fine as far as it goes, but it fails to consider the requirements of the pg_file_settings view: for that, we need to check validity of the value even though we have no intention to apply it. Because we didn't, even very silly values for affected GUCs would be reported as valid by the view. There are only half a dozen such GUCs, which perhaps explains why this got overlooked for so long. Fix by continuing when changeVal is false; this parallels the logic in some other early-exit paths. Also, the check added by commit 924bcf4f1 to prevent GUC changes in parallel workers seems a few bricks shy of a load: it's evidently assuming that ereport(elevel, ...) won't return. Make sure we bail out if it does. The lack of trouble reports suggests that this is only a latent bug, i.e. parallel workers don't actually reach here with elevel < ERROR. (Per the code coverage report, we never reach here at all in the regression suite.) But we clearly don't want to risk proceeding if that does happen. Per report from Rıdvan Korkmaz. These are ancient bugs, so back-patch to all supported branches. Discussion: https://postgr.es/m/2089235.1703617353@sss.pgh.pa.us Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/cb88f44ec805a338eafe8b88c8f25b6eb1be5838 Modified Files -------------- src/backend/utils/misc/guc.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings @ 2023-12-26 22:58 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-26 22:58 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings view. set_config_option() bails out early if it detects that the option to be set is PGC_BACKEND or PGC_SU_BACKEND class and we're reading the config file in a postmaster child; we don't want to apply any new value in such a case. That's fine as far as it goes, but it fails to consider the requirements of the pg_file_settings view: for that, we need to check validity of the value even though we have no intention to apply it. Because we didn't, even very silly values for affected GUCs would be reported as valid by the view. There are only half a dozen such GUCs, which perhaps explains why this got overlooked for so long. Fix by continuing when changeVal is false; this parallels the logic in some other early-exit paths. Also, the check added by commit 924bcf4f1 to prevent GUC changes in parallel workers seems a few bricks shy of a load: it's evidently assuming that ereport(elevel, ...) won't return. Make sure we bail out if it does. The lack of trouble reports suggests that this is only a latent bug, i.e. parallel workers don't actually reach here with elevel < ERROR. (Per the code coverage report, we never reach here at all in the regression suite.) But we clearly don't want to risk proceeding if that does happen. Per report from Rıdvan Korkmaz. These are ancient bugs, so back-patch to all supported branches. Discussion: https://postgr.es/m/2089235.1703617353@sss.pgh.pa.us Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e87252ceb8dc5cffca7867a1458053f0ace51c31 Modified Files -------------- src/backend/utils/misc/guc.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings @ 2023-12-26 22:58 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-26 22:58 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings view. set_config_option() bails out early if it detects that the option to be set is PGC_BACKEND or PGC_SU_BACKEND class and we're reading the config file in a postmaster child; we don't want to apply any new value in such a case. That's fine as far as it goes, but it fails to consider the requirements of the pg_file_settings view: for that, we need to check validity of the value even though we have no intention to apply it. Because we didn't, even very silly values for affected GUCs would be reported as valid by the view. There are only half a dozen such GUCs, which perhaps explains why this got overlooked for so long. Fix by continuing when changeVal is false; this parallels the logic in some other early-exit paths. Also, the check added by commit 924bcf4f1 to prevent GUC changes in parallel workers seems a few bricks shy of a load: it's evidently assuming that ereport(elevel, ...) won't return. Make sure we bail out if it does. The lack of trouble reports suggests that this is only a latent bug, i.e. parallel workers don't actually reach here with elevel < ERROR. (Per the code coverage report, we never reach here at all in the regression suite.) But we clearly don't want to risk proceeding if that does happen. Per report from Rıdvan Korkmaz. These are ancient bugs, so back-patch to all supported branches. Discussion: https://postgr.es/m/2089235.1703617353@sss.pgh.pa.us Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ea61b1cf6470fc267253962dd34fd20d16ead40d Modified Files -------------- src/backend/utils/misc/guc.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings @ 2023-12-26 22:58 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-26 22:58 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings view. set_config_option() bails out early if it detects that the option to be set is PGC_BACKEND or PGC_SU_BACKEND class and we're reading the config file in a postmaster child; we don't want to apply any new value in such a case. That's fine as far as it goes, but it fails to consider the requirements of the pg_file_settings view: for that, we need to check validity of the value even though we have no intention to apply it. Because we didn't, even very silly values for affected GUCs would be reported as valid by the view. There are only half a dozen such GUCs, which perhaps explains why this got overlooked for so long. Fix by continuing when changeVal is false; this parallels the logic in some other early-exit paths. Also, the check added by commit 924bcf4f1 to prevent GUC changes in parallel workers seems a few bricks shy of a load: it's evidently assuming that ereport(elevel, ...) won't return. Make sure we bail out if it does. The lack of trouble reports suggests that this is only a latent bug, i.e. parallel workers don't actually reach here with elevel < ERROR. (Per the code coverage report, we never reach here at all in the regression suite.) But we clearly don't want to risk proceeding if that does happen. Per report from Rıdvan Korkmaz. These are ancient bugs, so back-patch to all supported branches. Discussion: https://postgr.es/m/2089235.1703617353@sss.pgh.pa.us Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/76dd3d94a50435f57efc4da29e27a1bf69862726 Modified Files -------------- src/backend/utils/misc/guc.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2023-12-26 22:58 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2023-12-26 22:58 pgsql: Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings Tom Lane <tgl@sss.pgh.pa.us> 2023-12-26 22:58 pgsql: Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings Tom Lane <tgl@sss.pgh.pa.us> 2023-12-26 22:58 pgsql: Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings Tom Lane <tgl@sss.pgh.pa.us> 2023-12-26 22:58 pgsql: Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings Tom Lane <tgl@sss.pgh.pa.us> 2023-12-26 22:58 pgsql: Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings Tom Lane <tgl@sss.pgh.pa.us> 2023-12-26 22:58 pgsql: Fix failure to verify PGC_[SU_]BACKEND GUCs in pg_file_settings Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox