In an internal conversation it was seen that for some tests that want to enforce a behaviour, a behaviour that is controlled by a GUC, we _need_ to perform a sleep for an arbitrary amount of time. Alternatively, executing the rest of the test on a new connection also helps to get the expected behaviour. Following is a sample snippet of such a test.
ALTER SYSTEM SET param TO value; SELECT pg_reload_conf(); -- Either pg_sleep(0.1) or \connect here for next command to behave as expected. ALTER ROLE ... PASSWORD '...'; This is because of the fact that the SIGHUP, sent to Postmaster by this backend, takes some time to get back to the issuing backend. Although a pg_sleep() call works to alleviate the pain in most cases, it does not provide any certainty. Following the Principle Of Least Astonishment, we want a command that loads the configuration _synchronously_, so that the subsequent commands from the client can be confident that the requisite parameter changes have taken effect. The attached patch makes the pg_reload_conf() function set ConfigReloadPending to true, which will force the postgres main command-processing loop to process and apply config changes _before_ executing the next command. The only downside I can think of this approach is that it _might_ cause the issuing backend to process the config file twice; once after it has processed the current command, and another time when the SIGHUP signal comes from the Postmaster. If the SIGHUP signal from the Postmaster comes before the end of current command, then the issuing backend will process the config only once, as before the patch. In any case, this extra processing of the config seems harmless, and the benefit outweighs the extra processing done. The alternate methods that I considered (see branch reload_my_conf at [2]) were to either implement the SQL command RELOAD CONFIGURATION [ FOR ALL ], or to create an overloaded version of function pg_reload_conf(). But both those approaches had much more significant downsides, like additional GRANTs, etc. There have been issues identified in the past (see [1]) that possibly may be alleviated by this approach of applying config changes synchronously. [1]: https://www.postgresql.org/message-id/2138662.1623460441%40sss.pgh.pa.us [2]: https://github.com/gurjeet/postgres/tree/reload_my_conf Best regards, Gurjeet http://Gurje.et
reload_conf_synchronouly.patch
Description: Binary data