RE: memory leak in logical WAL sender with pgoutput's cachectx - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: memory leak in logical WAL sender with pgoutput's cachectx
Date
Msg-id OSCPR01MB14966A4407EDF6111B5E49485F535A@OSCPR01MB14966.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: memory leak in logical WAL sender with pgoutput's cachectx  (Xuneng Zhou <xunengzhou@gmail.com>)
Responses RE: memory leak in logical WAL sender with pgoutput's cachectx
List pgsql-hackers
Dear Xuneng,

> Is it safe to free the substructure from within rel_sync_cache_relation_cb()?

You referred the comment in rel_sync_cache_relation_cb() right? I understood like
that we must not access to any *system caches*, from the comment. Here we do not
re-build caches so that we do not access to the syscaches - it is permitted.
I'm happy if you also confirm the point.

> I’ also interested in the reasoning behind setting
> NINVALIDATION_THRESHOLD to 100.

This is the debatable point of this implementation. I set to 100 because it was
sufficient with the provided workload, but this may cause the replication lag.
We may have to consider a benchmark workload, measure data, and consider the
appropriate value. 100 is just an initial point.

Best regards,
Hayato Kuroda
FUJITSU LIMITED


pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Improve pg_sync_replication_slots() to wait for primary to advance
Next
From: Heikki Linnakangas
Date:
Subject: Re: BackendKeyData is mandatory?