Re: [Patch] ALTER SYSTEM READ ONLY
От | Amul Sul |
---|---|
Тема | Re: [Patch] ALTER SYSTEM READ ONLY |
Дата | |
Msg-id | CAAJ_b95QavfAu+P6X5XaqoDV+sTGQ-ATzSzSVacXC1sReTCKMw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Patch] ALTER SYSTEM READ ONLY (Amul Sul <sulamul@gmail.com>) |
Ответы |
Re: [Patch] ALTER SYSTEM READ ONLY
|
Список | 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@gmail.com> wrote: > > 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
Вложения
В списке pgsql-hackers по дате отправления: