From: "osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>
To: 'Kyotaro Horiguchi' <horikyota.ntt@gmail.com>, "sawada.mshk@gmail.com"
	<sawada.mshk@gmail.com>
CC: "bdrouvot@amazon.com" <bdrouvot@amazon.com>,
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
	"minsoo@amazon.com" <minsoo@amazon.com>
Subject: RE: [BUG] Logical replication failure "ERROR: could not map filenode
 "base/13237/442428" to relation OID" with catalog modifying txns
Thread-Topic: [BUG] Logical replication failure "ERROR: could not map filenode
 "base/13237/442428" to relation OID" with catalog modifying txns
Thread-Index: 
 AQHXGbjuwj9mOYhXQ0usEsUaX8Hh96qEyXkAgNWph4CAWAfvAIAVtt8AgAHNMoCABJ+9gIAEcjQAgAfgvlA=
Date: Tue, 19 Oct 2021 02:45:24 +0000
Message-ID: 
 <OSBPR01MB48886D77AC8AD25B16C28B5CEDBD9@OSBPR01MB4888.jpnprd01.prod.outlook.com>
References: 
 <CAD21AoAn-k6OpZ6HSAH_G91tpTXR6KYvkf663kg6EqW-f6sz1w@mail.gmail.com>
	<20211008.165055.1621145185927268721.horikyota.ntt@gmail.com>
	<CAD21AoD00wV4gt-53ze+ZB8n4bqJrdH8J_UnDHddy8S2A+a25g@mail.gmail.com>
 <20211014.112128.1398650206608979125.horikyota.ntt@gmail.com>
In-Reply-To: <20211014.112128.1398650206608979125.horikyota.ntt@gmail.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
msip_labels: MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_Enabled=true;
 MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_SetDate=2021-10-19T02:45:22Z;
 MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_Method=Standard;
 MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_Name=FUJITSU-RESTRICTED?;
 MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_SiteId=a19f121d-81e1-4858-a9d8-736e267fd4c7;
 MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_ActionId=a9e50502-1891-494b-b3b8-879e410d482f;
 MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_ContentBits=0
authentication-results: gmail.com; dkim=none (message not signed)
 header.d=none;gmail.com; dmarc=none action=none header.from=fujitsu.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c82a1d06-90f2-4622-7b3d-08d992aa809b
x-ms-traffictypediagnostic: OSBPR01MB5240:
x-microsoft-antispam-prvs: 
 <OSBPR01MB5240A2DCDB2BF3DB6AA59DD8EDBD9@OSBPR01MB5240.jpnprd01.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5236;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 
 NMD3gAW8dJ7gNy+d1A7GkYTEMByYDH0oFrEwPemd8YcGTCQtmv+wAlxQCq/JsI7Bzft1QYlO9GNbYKstTW75TCvQnBaWZbGbkWV6qDidPNi7k8dEpihqUKAP2r4I096iymrBZaKR/6kyRJm03rS3W6NmtkfmdFjTx6tF7nLYJ3Oj6cPWL8t9M6c+uA0ugQWReRfRakSubt+ZMdYX+FvQwmPqn6SSqBnjSSONC08W0MC5FsxT9CQZOdU6qiIrZktPlVbQPcandd6+A6KQdS/ZXkQMiEZn4yhCq0w7yagTBrruErGZByUQvdsy7aKDG+k3sQyW8z/R4bdL7pf7ii3gIYQMgQWfXS58rii0BFPSpQK2psNikS7UjDQ/rkz0UZ7ju3SqpXl26t8hSIDhaBzj+cQ+xHHhB+rv/psRR49PfbSj0Z/ixH/AYTIUBcC9BFPbh7pSz0muWjDIPMlRB0nDN7iopWxoy39WXE3tTlWDgT10uTUpXhmQzNjTDEMU8mp4z9Q3Jj+Vm3EP2ApTmbsf2MyOFRg4MIO2Q6NIviuldEo+zXrgew2PxC56dIq/E28TeeC7msSvjKXlaBuU34X2DOcdpzf99sLMxzwSO6y8ZUvYxCYwdo4wnF+PPk3wX5lklcsZqqfZ5R1MyYVXAl/vkSIVEyW8hPRbkNiRvdvIGcrLSqKmHeritWEEvS+qt1/NqPozV6A4YJm5G9pquocEQRR3O37DBMkmk0uMlF8kqykWbID3mLGrVcvhZLt3Q/Wl54uv+ezTzdoRFcJEF9SJtHv3q8hYqPwp6noHLwc5yVg=
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OSBPR01MB4888.jpnprd01.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(366004)(53546011)(54906003)(966005)(508600001)(33656002)(52536014)(7696005)(66946007)(6506007)(4326008)(8936002)(26005)(55016002)(8676002)(66476007)(64756008)(85182001)(66446008)(71200400001)(76116006)(186003)(82960400001)(66556008)(122000001)(38100700002)(316002)(83380400001)(38070700005)(9686003)(110136005)(5660300002)(86362001)(2906002);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?iso-2022-jp?B?RjVFTEhoWkVRY2NXSmFJMHJ0cEtkNGtpa2lic0dGYmZvSTU3TnRnbkwv?=
 =?iso-2022-jp?B?dzZtRnRXTXNRbXc5Uy9XT1owWmVVUnhNQ0drb1BaUG10dnExWUJ4Wmts?=
 =?iso-2022-jp?B?Q29yQnlkaHBmMWl0SDNLaEF6TXJyZU1wdFpwUTUyRzhLNXJEYUlsZFNN?=
 =?iso-2022-jp?B?c3FCbWZ5aFhsVzJqdkFDZFptVG1BV25JaUl1Y2orZHQ4aHNhTzZOZ1J1?=
 =?iso-2022-jp?B?S2hlbnlKZThrdTIzSFBWVGVGdmhHSEUxZ3NrcWZjUW95NXFIQyt5aktZ?=
 =?iso-2022-jp?B?SDhqL0YzNjVRS0FSSG9OUlBTcGJWc2tydjZvUVQ2azNLMTVvTnV1cHZj?=
 =?iso-2022-jp?B?LzZpWW5CWGtkL2JRYTlwdFh4N0t4dThOQkRuMXBGcUcwdU1sYUpjSk1q?=
 =?iso-2022-jp?B?UUcwZVE1ZHZGaFU0dFhTd1AzWmk0amNQNG9MWjVUNkdLZmZ1UzllMko0?=
 =?iso-2022-jp?B?Tld1Z3UzeFNwakppNkYxRUpKWkZQMU9YQUhEaFQrbnJWZzk1ZDRMYVls?=
 =?iso-2022-jp?B?M2ZTZnBiMXJSdnZKVDNibDQ4UFozUnlPaVRWNUoxZytveklyMHh5aWh1?=
 =?iso-2022-jp?B?OTN5R3YyVFJnV0pxYUVCT3ErYiswYS80UGJEN2RvUlQwUlc1a2xxaWc1?=
 =?iso-2022-jp?B?S0tDek9DajhHNjc2dkFBV2RUVHlyQ1RmMXJMTXg5c08rY1VsMXpHd0Ex?=
 =?iso-2022-jp?B?QytMRThKWTZPS2dFZi9jRXdIQkRWRng4c1MzNzV3V0lsTE1ZWU1JelZJ?=
 =?iso-2022-jp?B?QUt4b2wzRzBlTHRrY21DeUFTR1VJNGZwaTk0SURqSGo4VDlrNVZGcjRj?=
 =?iso-2022-jp?B?WWVpV3c5T3B4ZHNrWFpBWWRVdmY4b25OY3RVMm9sdCs0NGZvTWdWUWFs?=
 =?iso-2022-jp?B?NnZQclZxc0h0OXkrdG1MTlFWczhNdmhXRklpanVIMmFablpqWXZRYnZl?=
 =?iso-2022-jp?B?MkxiOXdUbCtXakw3Q1dYL2NuYU5vQUR2T1QxcVEwZHcvZ0JqSi9NeEp5?=
 =?iso-2022-jp?B?OTlOa3FkaEIrTFZiNFJGenZjdTgvUjhadlNvRlNCTmJuam5EcFN0Y2pa?=
 =?iso-2022-jp?B?Y2RvMEY5ZC9NaEZibTBHT0puTlcwNXIvN05RSnlXYWQ0RXNhbkYwNnJS?=
 =?iso-2022-jp?B?RmdUazVwSXk1ZWg5N0dzZkpxQ2FCeittUFU5VDZXa1ZWZm9hbGpIV2NW?=
 =?iso-2022-jp?B?MjBUY0VTemJYejlEZkNKQkhaQzdPNXJNRTFxdWtLUU1MZFFTdWRpNkZG?=
 =?iso-2022-jp?B?Q3hnTjRHRzF4S3ZsV1JGQXNLZ0p6ajZVMExHS0JNQnRJb2hOVmg2Tjdm?=
 =?iso-2022-jp?B?RW9laFJjSEtFT2ZQUk1ocXZBd2kvZFhudGVXOGZRdjB2eDQ2SUdEL200?=
 =?iso-2022-jp?B?d1QvbmliUFNNa25wTUpSUy95RlhLNDFpVEdIUnFKdk1STGwzRHZkTDdx?=
 =?iso-2022-jp?B?eElQOWFWY2tFejk5YWQwa3MwdVFqd2N4S1F0NklxZzJtRURoa2FiNTlk?=
 =?iso-2022-jp?B?Z3FUVHk0SXhCUEs5RVJrSTYwenlHT1BaaGc3OUJ4cHlza1BkUUxwd3pt?=
 =?iso-2022-jp?B?dnRwa1lrQ2JUeWNSaUpDcVU0VUdBQm4rT2NHeFdIWWVOcXBUNjlKSmU0?=
 =?iso-2022-jp?B?Qk5mZTQ0bEhhMkc3YWk0MUlKNFZ6MStEdFdpZWRRKzF0eENteHFjYVpZ?=
 =?iso-2022-jp?B?QzhWRUxCNTdrbmtmdnVXRlZ2allDZ2RBSERlTE5rYlFlZzJkZEJ5M2JR?=
 =?iso-2022-jp?B?ZWhjeVR5UXk3RFFyR3J4amQ0bnlKUnNyU1pLaS9Cbjk3Uzg5MW4rWFJB?=
 =?iso-2022-jp?B?elBXUjZuK3hoSytpTHdVN1lGNlZSUS84VkJiMHlUZlp2Mjc0enZqb04r?=
 =?iso-2022-jp?B?WXhMZW15T2xkb1Q0ZDlEYTJIcUowPQ==?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: fujitsu.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: OSBPR01MB4888.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 
 c82a1d06-90f2-4622-7b3d-08d992aa809b
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2021 02:45:24.8725
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a19f121d-81e1-4858-a9d8-736e267fd4c7
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 
 02eMySvWtstWjqwSRi3hocQWFWbBuJOcZBVNcULf1kQ43G4oRRi8A2cLhXXimz5JMiZjuJ1/zvIEzN3FExFAmGG2IKLpdZEfK3W2LCcNgTQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB5240
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/OSBPR01MB48886D77AC8AD25B16C28B5CEDBD9%40OSBPR01MB4888.jpnprd01.prod.outlook.com>
Precedence: bulk

On Thursday, October 14, 2021 11:21 AM Kyotaro Horiguchi <horikyota.ntt@gma=
il.com> wrote:
> At Mon, 11 Oct 2021 15:27:41 +0900, Masahiko Sawada
> <sawada.mshk@gmail.com> wrote in
> >
> > On Fri, Oct 8, 2021 at 4:50 PM Kyotaro Horiguchi
> > <horikyota.ntt@gmail.com> wrote:
> > > I came up with the third way.  SnapBuildCommitTxn already properly
> > > handles the case where a ReorderBufferTXN with
> > > RBTXN_HAS_CATALOG_CHANGES.  So this issue can be resolved by
> create
> > > such ReorderBufferTXNs in SnapBuildProcessRunningXacts.
> >
> > Thank you for the idea and patch!
> >
> > It's much simpler than mine. I think that creating an entry of a
> > catalog-changed transaction in the reorder buffer before
> > SunapBuildCommitTxn() is the right direction.
> >
> > After more thought, given DDLs are not likely to happen than DML in
> > practice, probably we can always mark both the top transaction and its
> > subtransactions as containing catalog changes if the commit record has
> > XACT_XINFO_HAS_INVALS? I believe this is not likely to lead to
> > overhead in practice. That way, the patch could be more simple and
> > doesn't need the change of AssertTXNLsnOrder().
> >
> > I've attached another PoC patch. Also, I've added the tests for this
> > issue in test_decoding.
>=20
> Thanks for the test script. (I did that with TAP framework but isolation =
tester
> version is simpler.)
>=20
> It adds a call to ReorderBufferAssignChild but usually subtransactions ar=
e
> assigned to top level elsewherae.  Addition to that
> ReorderBufferCommitChild() called just later does the same thing.  We are
> adding the third call to the same function, which looks a bit odd.
It can be odd. However, we
have a check at the top of ReorderBufferAssignChild
to judge if the sub transaction is already associated or not
and skip the processings if it is.

> And I'm not sure it is wise to mark all subtransactions as "catalog chang=
ed"
> always when the top transaction is XACT_XINFO_HAS_INVALS.
In order to avoid this,
can't we have a new flag (for example, in reorderbuffer struct) to check
if we start decoding from RUNNING_XACTS, which is similar to the first patc=
h of [1]
and use it at DecodeCommit ? This still leads to some extra specific codes =
added
to DecodeCommit and this solution becomes a bit similar to other previous p=
atches though.


[1] - https://www.postgresql.org/message-id/81D0D8B0-E7C4-4999-B616-1E5004D=
BDCD2%40amazon.com


Best Regards,
	Takamichi Osumi
=20