From: | Amul Sul <sulamul(at)gmail(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(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 13:26:22 |
Message-ID: | CAAJ_b95Of-pvgX75CJ9Z19nJDH-TFx1ZCBF7U0o=fi59eR4bpw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 11, 2021 at 6:48 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Tue, May 11, 2021 at 4:50 PM Amul Sul <sulamul(at)gmail(dot)com> wrote:
> >
> > On Tue, May 11, 2021 at 4:13 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > > I might be missing something, but assume the behavior should be like this
> > >
> > > 1. If the state is getting changed from WALPROHIBIT_STATE_READ_WRITE
> > > -> WALPROHIBIT_STATE_READ_ONLY, then as soon as the backend process
> > > the barrier, we can immediately abort any read-write transaction(and
> > > stop allowing WAL writing), because once we ensure that all session
> > > has responded that now they have no read-write transaction then we can
> > > safely change the state from WALPROHIBIT_STATE_GOING_READ_ONLY to
> > > WALPROHIBIT_STATE_READ_ONLY.
> > >
> >
> > Yes, that's what the current patch is doing from the first patch version.
> >
> > > 2. OTOH, if we are changing from WALPROHIBIT_STATE_READ_ONLY ->
> > > WALPROHIBIT_STATE_READ_WRITE, then we don't need to allow the backend
> > > to consider the system as read-write, instead, we should wait until
> > > the shared state is changed to WALPROHIBIT_STATE_READ_WRITE.
> > >
> >
> > I am sure that only not enough will have the same issue where
> > LocalXLogInsertAllowed gets set the same as the read-only as described in
> > my previous reply.
>
> Okay, but while browsing the code I do not see any direct if condition
> based on the "LocalXLogInsertAllowed" variable, can you point me to
> some references?
> I only see one if check on this variable and that is in
> XLogInsertAllowed() function, but now in XLogInsertAllowed() function,
> you are already checking IsWALProhibited. No?
>
I am not sure I understood this. Where am I checking IsWALProhibited()?
IsWALProhibited() is called by XLogInsertAllowed() once when
LocalXLogInsertAllowed is in a reset state, and that result will be
cached in LocalXLogInsertAllowed and will be used in the subsequent
XLogInsertAllowed() call.
Regards,
Amul
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2021-05-11 13:58:20 | Re: Performance degradation of REFRESH MATERIALIZED VIEW |
Previous Message | vignesh C | 2021-05-11 13:24:42 | Re: Enhanced error message to include hint messages for redundant options error |