| From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
|---|---|
| To: | Amul Sul <sulamul(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [Patch] ALTER SYSTEM READ ONLY |
| Date: | 2021-05-11 08:56:19 |
| Message-ID: | CAFiTN-tjhxP4i+MhWE3uyMDRwpiT0aK_S_F1bXQOYv6GS49ssw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, May 11, 2021 at 2:16 PM Amul Sul <sulamul(at)gmail(dot)com> wrote:
> I get why you think that, I wasn't very precise in briefing the problem.
>
> Any new backend that gets connected right after the shared memory
> state changes to WALPROHIBIT_STATE_GOING_READ_WRITE will be by
> default allowed to do the WAL writes. Such backends can perform write
> operation before the checkpointer does the XLogAcceptWrites().
Okay, make sense now. But my next question is why do we allow backends
to write WAL in WALPROHIBIT_STATE_GOING_READ_WRITE state? why don't we
wait until the shared memory state is changed to
WALPROHIBIT_STATE_READ_WRITE?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2021-05-11 08:56:46 | Re: Inherited UPDATE/DELETE vs async execution |
| Previous Message | Julien Rouhaud | 2021-05-11 08:52:19 | Re: compute_query_id and pg_stat_statements |