Re: Logical replication timeout problem

This is exactly our initial analysis and we have tried a patch on

these lines and it has a noticeable overhead. See [1]. Calling this

for each change or each skipped change can bring noticeable overhead

that is why we decided to call it after a certain threshold (100) of

skipped changes. Now, surely as mentioned in my previous reply we can

make it generic such that instead of calling this (update_progress

function as in the patch) for skipped cases, we call it always. Will

that make it better?

> The functions CreateInitDecodingContext and CreateDecodingContext receives the

> update_progress function as a parameter. These functions are called in 2

> places: (a) streaming replication protocol (CREATE_REPLICATION_SLOT) and (b)

> SQL logical decoding functions (pg_logical_*_changes). Case (a) uses

> WalSndUpdateProgress as a progress function. Case (b) does not have one because

> it is not required -- local decoding/communication. There is no custom update

> progress routine for each output plugin which leads me to the question:

> couldn't we encapsulate the update progress call into the callback functions?

>

Sorry, I don't get your point. What exactly do you mean by this?

AFAIS, currently we call this output plugin API in pgoutput functions

only, do you intend to get it invoked from a different place?