Re: Make reorder buffer max_changes_in_memory adjustable?

Thanks, Tomas.

> Theoretically, yes, we could make max_changes_in_memory a GUC, but it's
> not clear to me how would that help 12/13, because there's ~0% chance
> we'd backpatch that ...

What I mean is not about back-patch work. Things should happen on publisher
side?

Consider when the publisher is a PostgreSQL v14+~master (with streaming
support) and subscriber is a 12/13 where streaming is not supported, the
publisher
would still have the risk of OOM. The same thing should happen when we use a
v14+~master as publisher and a whatever open source CDC as subscriber.

> Wouldn't it be better to have adjusts the value automatically, somehow?
> For example, before restoring the changes, we could count the number of
> transactions, and set it to 4096/ntransactions or something like that.
> Or do something smarter by estimating tuple size, to count it in the
> logical__decoding_work_mem budget.

Yes, I think this issue should have been solved when
logical_decoding_work_mem
was initially been introduced, but it didn't. There could be some reasons
like
sub-transaction stuff which has been commented in the header of
reorderbuffer.c.

regards, Jingtang