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

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