On Fri, Mar 19, 2021 at 7:17 PM Prabhat Sahu
<prabhat.sahu@enterprisedb.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
anotherserver 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
