> On Sep 10, 2021, at 9:56 AM, Robert Haas <robertmh...@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 believe the 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 handed than something which merely sets a
flag asking the backend to exit. I was reading that as more immediate and then
trying 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 heavier handed than it is.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company