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

On Mon, May 26, 2025 at 2:52 PM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> > If the above hypothesis is true, we need to consider another idea so
> > that we can execute invalidation messages in both cases.
>
> The straightforward fix is to check the change queue as well when the transaction
> has invalidation messages. 0003 implemented that. One downside is that traversing
> changes can affect performance. Currently we iterates all of changes even a
> single REORDER_BUFFER_CHANGE_INVALIDATION. I cannot find better solutions for now.
>

It can impact the performance for large transactions with fewer
invalidations, especially the ones which has spilled changes because
it needs to traverse the entire list of changes again at the end. The
other idea would be to add new member(s) in ReorderBufferTXN to
receive distributed invalidations. For adding the new member in
ReorderBufferTXN: (a) in HEAD, it should be okay, (b) for
backbranches, we may be able to add at the end, but we should check if
there are any extensions using sizeof(ReorderBufferTxn) and if they
are using what we need to do.

I think the new member could be similar to existing members (uint32
ninvalidations; and SharedInvalidationMessage *invalidations;) or a
separate change queue of only REORDER_BUFFER_CHANGE_INVALIDATION
messages. The second one is worth considering because multiple
transactions can distribute their invalidations to a single txn in
chunks, which can be stored as separate changes, and the other benefit
of the second one is lower risk of the need for a larger chunk of
memory allocation due to repalloc. Also, it would be easy to consider
its size via ReorderBufferChangeMemoryUpdate.

--
With Regards,
Amit Kapila.