Re: DDL result is lost by CREATE DATABASE with WAL_LOG strategy
От | Dilip Kumar |
---|---|
Тема | Re: DDL result is lost by CREATE DATABASE with WAL_LOG strategy |
Дата | |
Msg-id | CAFiTN-vHa7RoAuk4yG_t=z+dnN4B64a0s-TCYBnM-LrbrE-QMg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: DDL result is lost by CREATE DATABASE with WAL_LOG strategy (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: DDL result is lost by CREATE DATABASE with WAL_LOG strategy
|
Список | pgsql-hackers |
On Thu, Feb 16, 2023 at 12:11 PM Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Thu, Feb 16, 2023 at 02:26:55PM +0900, Michael Paquier wrote: > > So, if I am understanding this stuff right, this issue can create data > > corruption once a DDL updates any pages of pg_class stored in a > > template database that gets copied by this routine. In this case, the > > patch sent makes sure that any page copied will get written once a > > checkpoint kicks in. Shouldn't we have at least a regression test for > > such a scenario? The issue can happen when updating a template > > database after creating a database from it, which is less worrying > > than the initial impression I got, still I'd like to think that we > > should have some coverage as of the special logic this code path > > relies on for pg_class when reading its buffers. > > I was able to quickly hack together a TAP test that seems to reliably fail > before the fix and pass afterwards. There's probably a better place for > it, though... I think the below change is not relevant to this bug right? diff --git a/src/test/recovery/meson.build b/src/test/recovery/meson.build index 209118a639..6e9f8a7c7f 100644 --- a/src/test/recovery/meson.build +++ b/src/test/recovery/meson.build @@ -39,6 +39,7 @@ tests += { 't/031_recovery_conflict.pl', 't/032_relfilenode_reuse.pl', 't/033_replay_tsp_drops.pl', + 't/100_bugs.pl', ], }, } -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: