From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jelte Fennema-Nio <me(at)jeltef(dot)nl> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jacob Burroughs <jburroughs(at)instructure(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dave Cramer <davecramer(at)gmail(dot)com>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org> |
Subject: | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |
Date: | 2024-01-05 17:26:18 |
Message-ID: | CA+TgmoayH39KUAqFi3KzvY9AfWWcidG1a++YE02JmcUfnb4c=Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 5, 2024 at 12:20 PM Jelte Fennema-Nio <me(at)jeltef(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jelte Fennema-Nio | 2024-01-05 17:31:56 | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |
Previous Message | Robert Haas | 2024-01-05 17:23:25 | Re: Stack overflow issue |