Re: walsender performance regression due to logical decoding on standby changes - Mailing list pgsql-hackers

From Andres Freund
Subject Re: walsender performance regression due to logical decoding on standby changes
Date
Msg-id 20230522175254.dqfnbqntrgznzdgu@awork3.anarazel.de
Whole thread Raw
In response to RE: walsender performance regression due to logical decoding on standby changes  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Responses RE: walsender performance regression due to logical decoding on standby changes
List 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 by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Order changes in PG16 since ICU introduction
Next
From: Andres Freund
Date:
Subject: Re: PG 16 draft release notes ready