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