From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
---|---|
To: | 'Thadeus Anand' <thadeus(at)rmkv(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, vignesh C <vignesh21(at)gmail(dot)com>, Nantha kumar(dot)T(dot) <nanthad(at)gmail(dot)com> |
Subject: | RE: [CAUTION: SUSPECT SENDER] RE: [CAUTION: SUSPECT SENDER] RE: BUG #19029: Replication Slot size keeps increasing while logical subscription works fine |
Date: | 2025-08-27 03:39:31 |
Message-ID: | OSCPR01MB149664F3AA76E31CBEAA83AE1F538A@OSCPR01MB14966.jpnprd01.prod.outlook.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Dear Thadeus,
> I do not know or understand what a "spill" is.
As I wrote in a previous mail, logical decoding (and logical replication)
sometimes writes changes into the disk to avoid using too-much memory, and the
".spill" file is the fragment. This can happen when the total amount of decoded
changes exceeds logical_decoding_work_mem.
> I will look it up. But the tables that are part of the
> publication are not updated as part of any huge transaction. They may be part of some other
> long running procedures
Actually, logical decoding decodes all changes even if tables are not published,
and suppress outputting changes at commit phase. There was a proposal to skip
decoding such changes, it could not improve the performance though.
[1]: https://commitfest.postgresql.org/patch/5585/
Best regards,
Hayato Kuroda
FUJITSU LIMITED