| From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
|---|---|
| To: | 'Masahiko Sawada' <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, Xuneng Zhou <xunengzhou(at)gmail(dot)com>, 赵宇鹏(宇彭) <zhaoyupeng(dot)zyp(at)alibaba-inc(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | RE: memory leak in logical WAL sender with pgoutput's cachectx |
| Date: | 2025-08-18 06:30:18 |
| Message-ID: | OSCPR01MB1496670956541A05DA3C3DB3BF531A@OSCPR01MB14966.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dear Sawada-san,
> I've not verified, but even if that's true, IIUC only one relation's
> cache entry can set in_use to true at a time.
I also think so.
> If my understanding is
> correct, when the walsender accepts invalidation messages in
> logicalrep_write_tuple() as you mentioned, it doesn't release the
> cache of the relation whose change is being sent but does for other
> relations. It seems to me too aggressive to release caches compared to
> the current behavior.
Valid point. In some cases, publications can be altered then same relsync entries
would be added again.
So... first approach may be better from the perspective. Attached patch counts
the number of invalidated entries. There is a chance to cleanup them only at
COMMIT/ABORT/PREPARE time - hence in_use flag is not needed. Thought?
Best regards,
Hayato Kuroda
FUJITSU LIMITED
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-pgoutput-allow-cleaning-up-Relsync-cache-entries.patch | application/octet-stream | 9.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2025-08-18 06:32:15 | Re: Conflict detection for update_deleted in logical replication |
| Previous Message | James Pang | 2025-08-18 06:23:30 | Re: max_locks_per_transaction v18 |