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

On Wed, Jun 11, 2025 at 7:15 AM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> While reviewing patch for PG13, I found the doubtful point in ReorderBufferCommit().
>
> ```
> /*
>  * Every time the CommandId is incremented, we could
>  * see new catalog contents, so execute all
>  * invalidations.
>  */
> ReorderBufferExecuteInvalidations(txn->ninvalidations,
>   txn->invalidations);
> ```
>
> This is called when REORDER_BUFFER_CHANGE_INTERNAL_COMMAND_ID is dequeued from the
> change queue, and this part exists only in PG13 codebase.
> We are not sure whether we should execute txn->invalidations_distributed as well.
> This can affect below case:
>
>
> txn1: BEGIN; INSERT INTO d VALUES ('d1');
> txn2: ALTER PUBLICATION pb ADD TABLE d;
> txn1: CREATE TABLE another (id int);
> txn1: INSERT INTO d VALUES ('d2');
> txn1: COMMIT;
>   -> PG13                                          - no output
>   -> PG13 + v13 patch                              - no output
>   -> PG13 + v13 patch + additional inval execution - d2 can be replicated
>   -> (master - d2 can be replicated)
>
> Personally I think txn->invalidations_distributed is not needed to be executed
> because the spec seems bit complex,  but I want to know other opinion.
>

This is not new; we knew from the time we committed this in PG13 that
concurrent transactions wouldn't pick up DDL changes, but later
transactions should. See commit message of commit
247ee94150b6fe8906da51afadbedf8acf3c17cf in PG13 ("The fix for 13 is
different from what we did in branches 14 and above, such that for 13,
the concurrent DDL changes (from DDL types mentioned earlier) will be
visible for any newly started transactions...). So, the above is
expected behavior for PG-13.

-- 
With Regards,
Amit Kapila.