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  (Nathan Bossart <nathandbossart@gmail.com>)
RE: DDL result is lost by CREATE DATABASE with WAL_LOG strategy  ("Ryo Matsumura (Fujitsu)" <matsumura.ryo@fujitsu.com>)
Список 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 по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Time delayed LR (WAS Re: logical replication restrictions)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Dead code in ps_status.c