> On Sep 10, 2021, at 9:56 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> I think the relevant question here is not "could a signal handler
> fire?" but "can we hit a CHECK_FOR_INTERRUPTS()?". If the relevant
> question is the former, then there's no hope of ever making it work
> because there's always a race condition. But the signal handler is
> only setting flags whose only effect is to make a subsequent
> CHECK_FOR_INTERRUPTS() do something, so it doesn't really matter when
> the signal handler can run, but when CHECK_FOR_INTERRUPTS() can call
> ProcessInterrupts().
Ok, that makes more sense. I was reviewing the code after first reviewing the documentation changes, which lead me to
believethe system was designed to respond more quickly than that:
+ WAL prohibited is a read-only system state. Any permitted user can call
+ <function>pg_prohibit_wal</function> function to forces the system into
+ a WAL prohibited mode where insert write ahead log will be prohibited until
+ the same function executed to change that state to read-write. Like Hot
and
+ Otherwise, it will be <literal>off</literal>. When the user requests WAL
+ prohibited state, at that moment if any existing session is already running
+ a transaction, and that transaction has already been performed or planning
+ to perform wal write operations then the session running that transaction
+ will be terminated.
"forces the system" in the first part, and "at that moment ... that transaction will be terminated" sounds heavier
handedthan something which merely sets a flag asking the backend to exit. I was reading that as more immediate and
thentrying to figure out how the signal handling could possibly work, and failing to see how.
The README:
+Any
+backends which receive WAL prohibited system state transition barrier interrupt
+need to stop WAL writing immediately. For barrier absorption the backed(s) will
+kill the running transaction which has valid XID indicates that the transaction
+has performed and/or planning WAL write.
uses "immediately" and "will kill the running transaction" which reenforced the impression that this mechanism is
heavierhanded than it is.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company