Re: primary_conninfo missing from pg_stat_wal_receiver - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: primary_conninfo missing from pg_stat_wal_receiver
Date
Msg-id CAB7nPqReWixXN19MUJwpz4W3SPVR9yn6D+L1aqX229w02ohmXg@mail.gmail.com
Whole thread Raw
In response to Re: primary_conninfo missing from pg_stat_wal_receiver  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On Thu, Jun 30, 2016 at 9:35 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>> (2)
>>> +retry:
>>> +    SpinLockAcquire(&walrcv->mutex);
>>> +    if (!walrcv->ready_to_display)
>>> +    {
>>> +        SpinLockRelease(&walrcv->mutex);
>>> +        CHECK_FOR_INTERRUPTS();
>>> +        pg_usleep(1000);
>>> +        goto retry;
>>> +    }
>>> +    SpinLockRelease(&walrcv->mutex);
>>>
>>> ISTM that we will never be able to get out of this loop if walreceiver
>>> fails to connect to the master (e.g., password is wrong) after we enter
>>> this loop.
>>
>> Wouldn't it be cleaner to just return an error here instead of retrying?
>
> I prefer to return NULL. Now NULL is returned when walreceiver's pid is 0.
> We can just change this logic so that NULL is returned pid is 0 OR the
> flag is false.

OK, yes. That's indeed better this way. Need a patch?
-- 
Michael



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: primary_conninfo missing from pg_stat_wal_receiver
Next
From: Alvaro Herrera
Date:
Subject: Re: primary_conninfo missing from pg_stat_wal_receiver