Re: Timeout failure in

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Timeout failure in
Date: 2021-09-18 06:32:31
Message-ID: YUWH/
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, Sep 17, 2021 at 08:41:00PM -0700, Noah Misch wrote:
> If this fixes things for the OP, I'd like it slightly better than the "ps"
> approach. It's less robust, but I like the brevity.
> Another alternative might be to have walreceiver reach walsender via a proxy
> Perl script. Then, make that proxy able to accept an instruction to pause
> passing data until further notice. However, I like two of your options better
> than this one.

Could it be possible to rely on a combination of wait events set in WAL
senders and pg_stat_replication to assume that a WAL sender is in a
stopped state? I would think about something like that in the top of
my mind (perhaps this would need 2 WAL senders, one stopped and one
still running):
1) SIGSTOP WAL sender 1.
2) Check WAL sender 1 is in WalSenderMain. If not retry 1) after a
3) Generate some WAL, and look at pg_stat_replication to see if there
has been some progress in 1), but that 2) is done.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Habets 2021-09-18 10:57:05 Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert
Previous Message Michael Paquier 2021-09-18 06:18:16 Re: Teach pg_receivewal to use lz4 compression