From: | "Ryo Matsumura (Fujitsu)" <matsumura(dot)ryo(at)fujitsu(dot)com> |
---|---|
To: | 'Michael Paquier' <michael(at)paquier(dot)xyz>, Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(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-20 08:22:02 |
Message-ID: | TYCPR01MB6868597A22AB716BD6B43FEBE8A49@TYCPR01MB6868.jpnprd01.prod.outlook.com |
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.
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.
Thank you for comment and patch.
I think that the patch for dbcommand.c is fixed.
So I apply to my environment.
> 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..
I think so too. I was surprised that new strategy is default.
Regards
Ryo Matsumura
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2023-02-20 08:22:50 | Re: Support logical replication of DDLs |
Previous Message | Kyotaro Horiguchi | 2023-02-20 08:08:19 | Re: "out of relcache_callback_list slots" after multiple calls to pg_logical_slot_get_binary_changes |