Re: walsender performance regression due to logical decoding on standby changes

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: walsender performance regression due to logical decoding on standby changes
Дата
Msg-id 20230522175254.dqfnbqntrgznzdgu@awork3.anarazel.de
обсуждение исходный текст
Ответ на RE: walsender performance regression due to logical decoding on standby changes  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Ответы RE: walsender performance regression due to logical decoding on standby changes  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Список pgsql-hackers
Hi,

On 2023-05-22 12:15:07 +0000, Zhijie Hou (Fujitsu) wrote:
> About "a backend doing logical decoding", do you mean the case when a user
> start a backend and invoke pg_logical_slot_get_changes() to do the logical
> decoding ? If so, it seems the logical decoding in a backend won't be waked up
> by startup process because the backend won't be registered as a walsender so
> the backend won't be found in WalSndWakeup().

I meant logical decoding happening inside a walsender instance.


> Or do you mean the deadlock between the real logical walsender and startup
> process ? (I might miss something) I think the logical decoding doesn't lock
> the target user relation when decoding because it normally can get the needed
> information from WAL.

It does lock catalog tables briefly. There's no guarantee that such locks are
released immediately. I forgot the details, but IIRC there's some outfuncs
(enum?) that intentionally delay releasing locks till transaction commit.

Greetings,

Andres Freund



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

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Order changes in PG16 since ICU introduction
Следующее
От: Andres Freund
Дата:
Сообщение: Re: PG 16 draft release notes ready