From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, "Ryo Matsumura (Fujitsu)" <matsumura(dot)ryo(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: DDL result is lost by CREATE DATABASE with WAL_LOG strategy |
Date: | 2023-02-16 05:26:55 |
Message-ID: | Y+2+n4FuE6K5/1CX@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-02-16 05:34:00 | Re: Dead code in ps_status.c |
Previous Message | Kyotaro Horiguchi | 2023-02-16 05:21:01 | Re: Time delayed LR (WAS Re: logical replication restrictions) |