From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Amul Sul <sulamul(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com> |
Subject: | Re: [Patch] ALTER SYSTEM READ ONLY |
Date: | 2021-09-10 17:16:48 |
Message-ID: | 06461B58-237D-41F7-887C-D8A188A97E5E@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Sep 10, 2021, at 9:56 AM, Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2021-09-10 17:18:59 | Re: parallelizing the archiver |
Previous Message | Zhihong Yu | 2021-09-10 17:11:34 | incorrect file name in backend_progress.c header |