| From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
|---|---|
| To: | Amul Sul <sulamul(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(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-05-13 07:06:28 |
| Message-ID: | CAFiTN-u3TwHahAzSshTbpSka+KZ=O7EUN+BHTtcyZdzFiKgLZw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, May 12, 2021 at 5:55 PM Amul Sul <sulamul(at)gmail(dot)com> wrote:
>
Thanks for the updated patch, while going through I noticed this comment.
+ /*
+ * WAL prohibit state changes not allowed during recovery except the crash
+ * recovery case.
+ */
+ PreventCommandDuringRecovery("pg_prohibit_wal()");
Why do we need to allow state change during recovery? Do you still
need it after the latest changes you discussed here, I mean now
XLogAcceptWrites() being called before sending barrier to backends.
So now we are not afraid that the backend will write WAL before we
call XLogAcceptWrites(). So now IMHO, we don't need to keep the
system in recovery until pg_prohibit_wal(false) is called, right?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro Horiguchi | 2021-05-13 07:15:30 | Re: compute_query_id and pg_stat_statements |
| Previous Message | Amit Langote | 2021-05-13 06:32:04 | Re: Inherited UPDATE/DELETE vs async execution |