RE: Selectively invalidate caches in pgoutput module

Поиск
Список
Период
Сортировка
От Hayato Kuroda (Fujitsu)
Тема RE: Selectively invalidate caches in pgoutput module
Дата
Msg-id OSCPR01MB149669AF61681064D2A75FAE9F5D42@OSCPR01MB14966.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Selectively invalidate caches in pgoutput module  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы RE: Selectively invalidate caches in pgoutput module
Список pgsql-hackers
Dear Amit,

> Don't we need to call this invalidation function from
> InvalidateSystemCachesExtended()?

Hmm. I did not call relsync callback functions in InvalidateSystemCachesExtended()
intentionally, but added now. Please see my analysis below and let me know how
you think.

In the first place, InvalidateSystemCachesExtended() can be called by
1) InvalidateSystemCaches(), and 2) AcceptInvalidationMessages().

Regarding the 1), it could be used when a) the parallel worker is launched,
b) decoder starts decoding, or c) decoder finishes decoding and after decoding context is free'd.
However, parallel worker won't do a decoding, initially the relsync cache is empty
and relsync would be dropped when the decding context is removed.
Based on the fact I did not called the function.

As for the 2), the path exists only when the debug build mode and debug_discard_caches is set.
According to the manual and code comments, it must discard all caches anytime.
So...OK, I decided to follow the rule.

Best regards,
Hayato Kuroda
FUJITSU LIMITED


Вложения

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