On Tue, Jan 11, 2022 at 8:13 PM Fabrice Chapuis <fabrice636...@gmail.com> wrote:
> Can you explain why you think this will help in solving your current > problem? > > Indeed your are right this function won't help, we have to look elsewhere. > > It is still not clear to me why the problem happened? IIUC, after > restoring 4096 changes from snap files, we send them to the subscriber, and > then apply worker should apply those one by one. Now, is it taking one > minute to restore 4096 changes due to which apply worker is timed out? > > Now I can easily reproduce the problem. > In a first phase, snap files are generated and stored in pg_replslot. This > process end when1420 files are present in pg_replslots (this is in relation > with statements that must be replayed from WAL). In the pg_stat_replication > view, the state field is set to *catchup*. > In a 2nd phase, the snap files must be decoded. However after one minute > (wal_receiver_timeout parameter set to 1 minute) the worker process stop > with a timeout. > > What exactly do you mean by the first and second phase in the above description? -- With Regards, Amit Kapila.
