Re: Move walreceiver state assignment (to WALRCV_STREAMING) in WalReceiverMain()

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Euler Taveira <euler(at)eulerto(dot)com>
Cc: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Move walreceiver state assignment (to WALRCV_STREAMING) in WalReceiverMain()
Date: 2023-12-13 14:33:31
Message-ID: ZXnAuwAP0ZD_96QS@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 12, 2023 at 04:54:32PM -0300, Euler Taveira wrote:
> Couldn't it give up before starting if you apply your patch? My main concern is
> due to a slow system, the walrcv_connect() took to long in WalReceiverMain()
> and the code above kills the walreceiver while in the process to start it.
> Since you cannot control the hardcoded WALRCV_STARTUP_TIMEOUT value, you might
> have issues during overload periods.

Sounds like a fair point to me, this area is trickier than it looks.
Another thing that I'm a bit surprised with is why it would be OK to
switch the status to STREAMING only we first_stream is set, discarding
the restart case.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-12-13 14:40:40 Re: Subsequent request from pg client
Previous Message Michael Paquier 2023-12-13 14:23:14 Re: Remove MSVC scripts from the tree