From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Duncan Sands <duncan(dot)sands(at)deepbluecap(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 |
Date: | 2025-06-02 10:22:27 |
Message-ID: | CALDaNm2sGfKsZwm8rG132N_i0AvyxkYu8TL46kNcx7KwAUABxA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sat, 31 May 2025 at 13:27, vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Fri, 30 May 2025 at 23:00, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > Thank you for updating the patch. Here are some review comments:
> >
> > @@ -3439,9 +3464,27 @@ ReorderBufferAddInvalidations(ReorderBuffer
> > *rb, TransactionId xid,
> > XLogRecPtr lsn, Size nmsgs,
> > SharedInvalidationMessage *msgs)
> > {
> > - ReorderBufferTXN *txn;
> > + ReorderBufferAddInvalidationsExtended(rb, xid, lsn, nmsgs, msgs, false);
> > +}
> >
> > If the patch is the changes for master do we need to have an extended
> > version of ReorderBufferAddInvalidation()?
>
> This has been removed now and ReorderBufferAddDistributedInvalidtions
> has been added
>
> > ---
> > + /*
> > + * Make sure there's no cache pollution. Unlike the PG_TRY part,
> > + * this must be done unconditionally because the processing might
> > + * fail before we reach invalidation messages.
> > + */
> > + if (rbtxn_inval_all_cache(txn))
> > + InvalidateSystemCaches();
> > + else
> > + ReorderBufferExecuteInvalidations(txn->ninvalidations_distr,
> > +
> > txn->distributed_invalidations);
> > +
> >
> > If we don't need to execute the distributed inval message in an error
> > path other than detecting concurrent abort, we should describe the
> > reason.
>
> Removed it to keep it in the common error path
>
> > ---
> > Given that we don't account the memory usage of both
> > txn->invalidations and txn->distributed_invalidations, probably we can
> > have a lower limit, say 8MB (or lower?), to avoid memory exhaustion.
>
> Modified
>
> > ---
> > + if ((for_inval && !AllocSizeIsValid(req_mem_size)) ||
> > + rbtxn_inval_all_cache(txn))
> > {
> > - txn->ninvalidations = nmsgs;
> > - txn->invalidations = (SharedInvalidationMessage *)
> > - palloc(sizeof(SharedInvalidationMessage) * nmsgs);
> > - memcpy(txn->invalidations, msgs,
> > - sizeof(SharedInvalidationMessage) * nmsgs);
> > + txn->txn_flags |= RBTXN_INVAL_ALL_CACHE;
> > +
> > + if (*invalidations)
> > + {
> > + pfree(*invalidations);
> > + *invalidations = NULL;
> > + *ninvalidations = 0;
> > + }
> >
> > RBTXN_INVAL_ALL_CACHE seems to have an effect only on the distributed
> > inval messages. One question is do we need to care about the overflow
> > of txn->invalidations as well? If no, does it make sense to have a
> > separate function like ReorderBufferAddDistributedInvalidtions()
> > instead of having an extended version of
> > ReorderBufferAddInvalidations()? Some common routines can also be
> > declared as a static function if needed.
>
> Modified
>
> The attached v7 version patch has the changes for the same.
Here is the patch, including updates for the back branches.
The main difference from master is that the newly added structure
members are appended at the end in the back branches to preserve
compatibility. The invalidation addition logic remains consistent with
master: a new function, ReorderBufferAddDistributedInvalidations, has
been introduced to handle distributed invalidations. Shared logic
between ReorderBufferAddInvalidations and
ReorderBufferAddDistributedInvalidations has been factored out into a
common helper, ReorderBufferAddInvalidationsCommon. This approach
simplifies future merges and, in my assessment, does not introduce any
backward compatibility issues.
Regards,
Vignesh
Attachment | Content-Type | Size |
---|---|---|
v8-PG15-0001-Fix-exponential-memory-allocation-issue-in-l.patch | application/octet-stream | 12.0 KB |
v8-PG14-0001-Fix-exponential-memory-allocation-issue-in-l.patch | application/octet-stream | 11.9 KB |
v8-PG13-0001-Fix-exponential-memory-allocation-issue-in-l.patch | application/octet-stream | 11.1 KB |
v8-PG17-0001-Fix-exponential-memory-allocation-issue-in-l.patch | application/octet-stream | 11.9 KB |
v8-master-0001-Fix-exponential-memory-allocation-issue-in.patch | application/octet-stream | 12.0 KB |
v8-PG16-0001-Fix-exponential-memory-allocation-issue-in-l.patch | application/octet-stream | 11.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2025-06-02 11:35:36 | RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 |
Previous Message | Michael Paquier | 2025-06-02 08:13:48 | Re: BUG #18944: Assertion Failure in psql with idle_session_timeout Set |