Re: User defined data types in Logical Replication

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: User defined data types in Logical Replication
Дата
Msg-id CAD21AoAkAHv7P_wTJCUnoBHzxma_97P8KhtoBrzUVtPXmkQF4g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: User defined data types in Logical Replication  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: User defined data types in Logical Replication
Re: User defined data types in Logical Replication
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: RE: [HACKERS] Statement-level rollback
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] path toward faster partition pruning