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

From: vignesh C <vignesh21(at)gmail(dot)com>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, 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>, 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-22 02:57:49
Message-ID: CALDaNm1Fx+zzudTi1aoE9nFef_p4H-qbOcvF9_qRanNLtwU-tA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, 20 Jun 2025 at 13:51, Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> 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.

I agree with your analysis.

> 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.

Alternatively I was thinking of a fix if it is possible to run this
test conditionally when CLOBBER_CACHE_ALWAYS is not defined, I was not
sure if it is easy to do that and worth the effort for the PG13
branch. I'm ok with the proposed change.

Regards,
Vignesh

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alexander Lakhin 2025-06-22 12:00:01 Re: BUG #18953: Planner fails to build plan for complex query with LATERAL references
Previous Message Tom Lane 2025-06-21 21:46:18 Re: BUG #18960: Mistake in test test_simple_pipeline (libpq_pipeline.c)