On Fri, Jan 5, 2024 at 12:20 PM Jelte Fennema-Nio <m...@jeltef.nl> wrote: > They are not fundamentally transactional afaict based on the changes > that were needed so far. It makes sense too, because e.g. SIGHUP > should change the GUC value if the config changed no matter if the > current transaction aborts or succeeds.
Well, AtEOXact_GUC either reverts or puts back changes to GUC values that have happened in that (sub)transaction, depending on whether the (sub)transaction committed or aborted. To make that work, there's a "stack" of GUC values for any given setting. For a non-transactional value, we wouldn't have all that infrastructure... -- Robert Haas EDB: http://www.enterprisedb.com
