Re: User defined data types in Logical Replication - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: User defined data types in Logical Replication
Date
Msg-id CAD21AoAkAHv7P_wTJCUnoBHzxma_97P8KhtoBrzUVtPXmkQF4g@mail.gmail.com
Whole thread Raw
In response to Re: User defined data types in Logical Replication  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: User defined data types in Logical Replication
Re: User defined data types in Logical Replication
List pgsql-hackers
On Sat, Jan 6, 2018 at 3:53 AM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> hash_seq_init in logicalrep_typmap_invalidate_cb is useless after your
> patch.  If you remove it, the function becomes empty, so why is it there
> an invalidation callback at all?

Thank you for the comment. Yeah, logicalrep_typmap_invalidate_cb is no
longer needed. Attached an updated patch.

> Are we now leaking memory if types keep repeatedly being re-created in
> the origin?

The type name and namespace name in LogicalRepTyp are freed when
updating entries but LogicalRepTyp entry itself could be leaked. It
can happen to relation map as well. Since we don't remove hash entry
during working in the origin the hash map entry for relation map is
leaked if publication repeatedly adds/drops tables and subscription
refreshes it.

> I suppose it's not a common use pattern, but it'd be good
> to avoid everlasting memleaks.

I agree. Can we remove entry from hash table in the callbacks instead
of setting InvalidOid when invalidate caches?

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Attachment

pgsql-hackers by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: [HACKERS] Statement-level rollback
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] path toward faster partition pruning