Re: DDL result is lost by CREATE DATABASE with WAL_LOG strategy
От | Michael Paquier |
---|---|
Тема | Re: DDL result is lost by CREATE DATABASE with WAL_LOG strategy |
Дата | |
Msg-id | Y+2+n4FuE6K5/1CX@paquier.xyz обсуждение исходный текст |
Ответ на | Re: DDL result is lost by CREATE DATABASE with WAL_LOG strategy (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: DDL result is lost by CREATE DATABASE with WAL_LOG strategy
RE: DDL result is lost by CREATE DATABASE with WAL_LOG strategy |
Список | pgsql-hackers |
On Thu, Feb 16, 2023 at 10:24:13AM +0530, Dilip Kumar wrote: > Yes, there is no reason to pass this as false, seems like this is > passed false by mistake. And your patch fixes the issue. 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 have not given much attention to this area, but I am a bit suspicious that enforcing the default as WAL_LOG was a good idea for 15~, TBH. We are usually much more conservative when it comes to such choices, switching to the new behavior after a few years would have been wiser.. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: