From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
---|---|
To: | 'RECHTÉ Marc' <marc(dot)rechte(at)meteo(dot)fr> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | RE: Logical replication timeout |
Date: | 2024-12-23 11:17:47 |
Message-ID: | OSCPR01MB14966F2D6D3DFEDB631B4284BF5022@OSCPR01MB14966.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dear Marc,
Thanks for the reply!
> Thanks for your suggestions that were both already tested. In our (real) case (a
> single transaction with 12 millions sub-transactions):
>
> 1) setting the subscription as streaming, just delay a bit the spill file surge. It does
> not prevent the creation of spill files.
It is bit surprised for me because I don't know the path which transactions can
be serialized even in the streaming=on case. Let me think over it...
> 2) we set logical_decoding_work_mem to 20GB, which probably also delayed the
> problem, but did not solve it.
Oh, I understood that you've already increased the parameter to the appropriate
value on your env. Is it right?
Best regards,
Hayato Kuroda
FUJITSU LIMITED
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2024-12-23 11:30:17 | Re: transaction lost when delete clog file after normal shutdown |
Previous Message | Heikki Linnakangas | 2024-12-23 11:05:27 | Re: Exporting float_to_shortest_decimal_buf(n) with Postgres 17 on Windows |