RE: Fix apply worker crash when subscriber table has only a deferrable primary key - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Fix apply worker crash when subscriber table has only a deferrable primary key
Date
Msg-id OS7PR01MB18317E6204C1275E261DEB077F58B2@OS7PR01MB18317.jpnprd01.prod.outlook.com
Whole thread
In response to Re: Fix apply worker crash when subscriber table has only a deferrable primary key  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Fix apply worker crash when subscriber table has only a deferrable primary key
List pgsql-hackers
Hi Amit,

> The caller of RelationFindDeletedTupleInfoSeq() already has
> information localindexoid/idxisreplident, why can't we use those
> values instead of computing the same information again? I am afraid
> that computing such an information again could lead to symptoms what
> we fixed in the recent commit
> ad36e3608c8cb6f0848737ec81e548d4d3a0af3c.

Your point meant not to get the info from the relcache because it can be
invalidated by the concurrent DDLs, right? I think it's possible, but the
additional computation might be needed since bitmapset for key columns are not
cached on the relmap now. Attached top-up patch implemented the idea, can you
see it's same as your expectation?
Test code just showed my understanding, not intended to be included for now.

> I suggest let's first fix this one and then we can discuss your other patch.

Yeah, it's related with PG19 issue thus it has higher priority.

Best regards,
Hayato Kuroda
FUJITSU LIMITED


Attachment

pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Direct TOAST v2, faster, smaller and no migration needed
Next
From: Hannu Krosing
Date:
Subject: Re: Direct TOAST v2, faster, smaller and no migration needed