Re: User defined data types in Logical Replication

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

In response to

Responses

Browse pgsql-hackers by date

  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