From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Huong Dangminh <huo-dangminh(at)ys(dot)jp(dot)nec(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Hiroshi Yanagisawa <hir-yanagisawa(at)ut(dot)jp(dot)nec(dot)com> |
Subject: | Re: User defined data types in Logical Replication |
Date: | 2018-01-09 08:22:13 |
Message-ID: | CAD21AoAkAHv7P_wTJCUnoBHzxma_97P8KhtoBrzUVtPXmkQF4g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 6, 2018 at 3:53 AM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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 | Content-Type | Size |
---|---|---|
fix_slot_store_error_callback_v12.patch | application/octet-stream | 8.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2018-01-09 08:40:08 | Re: [HACKERS] path toward faster partition pruning |
Previous Message | Tsunakawa, Takayuki | 2018-01-09 08:21:33 | RE: [HACKERS] Statement-level rollback |