RE: logical apply worker's lock waits in subscriber can stall checkpointer in publisher

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'Fujii Masao' <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: logical apply worker's lock waits in subscriber can stall checkpointer in publisher
Date: 2026-01-30 04:19:55
Message-ID: TY7PR01MB14554694999282D899B73E2E3F59FA@TY7PR01MB14554.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Fujii-san,

> This approach doesn't seem helpful on platforms that don't support
> TCP_USER_TIMEOUT, i.e., tcp_user_timeout is not available. Right?
> If I remember correctly, Windows is one of those platforms.

Good point, documentation said it's not usable for Windows.
The easiest fix I can come up with is to determine a timeout for checkpoint wait;
ConditionVariableTimedSleep() can be used in InvalidatePossiblyObsoleteSlot(),
we can put some LOG and skip invalidating for a while. Not sure how long we
should wait but at least we can use the a fixed value. This might be similar
with your second option.
Regarding the first option, it can solve the root cause, but I'm afraid we may
have to modify very common code.

Best regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-01-30 04:31:38 Re: pg_upgrade: optimize replication slot caught-up check
Previous Message shveta malik 2026-01-30 04:15:46 Re: pg_upgrade: optimize replication slot caught-up check