From: | Amul Sul <sulamul(at)gmail(dot)com> |
---|---|
To: | Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com> |
Cc: | Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(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-04-05 05:31:16 |
Message-ID: | CAAJ_b95QavfAu+P6X5XaqoDV+sTGQ-ATzSzSVacXC1sReTCKMw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Attached is the rebase version for the latest master head(commit # 9f6f1f9b8e6).
Regards,
Amul
On Mon, Mar 22, 2021 at 12:13 PM Amul Sul <sulamul(at)gmail(dot)com> wrote:
>
> On Fri, Mar 19, 2021 at 7:17 PM Prabhat Sahu
> <prabhat(dot)sahu(at)enterprisedb(dot)com> wrote:
> >
> > Hi all,
> > While testing this feature with v20-patch, the server is crashing with below steps.
> >
> > Steps to reproduce:
> > 1. Configure master-slave replication setup.
> > 2. Connect to Slave.
> > 3. Execute below statements, it will crash the server:
> > SELECT pg_prohibit_wal(true);
> > SELECT pg_prohibit_wal(false);
> >
> > -- Slave:
> > postgres=# select pg_is_in_recovery();
> > pg_is_in_recovery
> > -------------------
> > t
> > (1 row)
> >
> > postgres=# SELECT pg_prohibit_wal(true);
> > pg_prohibit_wal
> > -----------------
> >
> > (1 row)
> >
> > postgres=# SELECT pg_prohibit_wal(false);
> > WARNING: terminating connection because of crash of another server process
> > DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
> > HINT: In a moment you should be able to reconnect to the database and repeat your command.
> > server closed the connection unexpectedly
> > This probably means the server terminated abnormally
> > before or while processing the request.
> > The connection to the server was lost. Attempting reset: Failed.
> > !?>
>
> Thanks Prabhat.
>
> The assertion failure is due to wrong assumptions for the flag that were used
> for the XLogAcceptWrites() call. In the case of standby, the startup process
> never reached the place where it could call XLogAcceptWrites() and update the
> respective flag. Due to this flag value, pg_prohibit_wal() function does
> alter system state in recovery state which is incorrect.
>
> In the attached function I took enum value for that flag so that
> pg_prohibit_wal() is only allowed in the recovery mode, iff that flag indicates
> that XLogAcceptWrites() has been skipped previously.
>
> Regards,
> Amul
Attachment | Content-Type | Size |
---|---|---|
v23-0001-Implement-wal-prohibit-state-using-global-barrie.patch | application/x-patch | 52.5 KB |
v23-0002-Error-or-Assert-before-START_CRIT_SECTION-for-WA.patch | application/x-patch | 69.9 KB |
v23-0003-Documentation.patch | application/x-patch | 10.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-04-05 05:47:17 | Re: Proposal: Save user's original authenticated identity for logging |
Previous Message | Kyotaro Horiguchi | 2021-04-05 05:07:18 | Re: badly calculated width of emoji in psql |