RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Duncan Sands <duncan(dot)sands(at)deepbluecap(dot)com>, 'vignesh C' <vignesh21(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>
Subject: RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5
Date: 2025-06-20 08:20:50
Message-ID: OSCPR01MB14966F91DBCAEA80EDEE67842F57CA@OSCPR01MB14966.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Dear hackers,

I've analyzed the issue, and this can always happen when --DCLOBBER_CACHE_ALWAYS is
set on PG13. My suggestion is to remove the latter part of test on this branch.

In the failed workload, we tested the case that one long transaction inserts a
tuple after the concurrent transaction does ALTER PUBLICATION ADD TABLE.
For PG14+ the change can be published, and PG13 it cannot be replicated because
the distributed inval messages cannot be executed during the transaction. That's
why we expected no results were output.

So what if the -DDCLOBBER_CACHE_ALWAYS is set for the workload? relsync cache
can be discarded very frequently and backend process always read the system
catalog when it processes their changes. This means decoder can recognize that the
pg_publication has been updated and it can publish changes based on the altered
publication information. This behavior is opposite from normal.

To fix the test failure, I suggest to just remove the case. Insert-after-commit
case has already been tested by above part of this file, so no need to do others.

Attached file does accordingly.

Best regards,
Hayato Kuroda
FUJITSU LIMITED

Attachment Content-Type Size
0001-Fix-oversight-by-1230be12.patch application/octet-stream 3.3 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Dilip Kumar 2025-06-20 11:29:10 Re: BUG #18959: Name collisions of expression indexes during parallel Index creations on a pratitioned table.
Previous Message Duncan Sands 2025-06-20 07:48:25 Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5