| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Fabrice Chapuis <fabrice636861(at)gmail(dot)com> |
| Cc: | Tang, Haiying/唐 海英 <tanghy(dot)fnst(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Logical replication timeout problem |
| Date: | 2021-12-23 10:51:58 |
| Message-ID: | CAA4eK1K0O27c7qbXE5V__LXZHi24jfR+B=JubHx2_a5gfiq+Pg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 22, 2021 at 8:50 PM Fabrice Chapuis <fabrice636861(at)gmail(dot)com> wrote:
>
> Hello Amit,
>
> I was able to reproduce the timeout problem in the lab.
> After loading more than 20 millions of rows in a table which is not replicated (insert command ends without error), errors related to logical replication processes appear in the postgres log.
> Approximately every 5 minutes worker process is restarted. The snap files in the slot directory are still present. The replication system seems to be blocked. Why these snap files are not removed. What do they contain?
>
These contain changes of insert. I think these are not removed for
your case as your long transaction is never finished. As mentioned
earlier, for such cases, it is better to use 'streaming' feature
released as part of PG-14 but anyway here we are trying to debug
timeout problem.
> I will recompile postgres with your patch to debug.
>
Okay, that might help.
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2021-12-23 11:16:02 | skip replication slot snapshot/map file removal during end-of-recovery checkpoint |
| Previous Message | Andrey Lepikhov | 2021-12-23 10:49:59 | Re: Add index scan progress to pg_stat_progress_vacuum |