Re: primary_conninfo missing from pg_stat_wal_receiver

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: primary_conninfo missing from pg_stat_wal_receiver
Дата
Msg-id CAHGQGwHY9c5zqtzxv4j0Wk3Uh9rOqaE5xabOL-N_+f4XZbszyg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: primary_conninfo missing from pg_stat_wal_receiver  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: primary_conninfo missing from pg_stat_wal_receiver  (Michael Paquier <michael.paquier@gmail.com>)
Re: primary_conninfo missing from pg_stat_wal_receiver  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
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.

Regards,

-- 
Fujii Masao



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: primary_conninfo missing from pg_stat_wal_receiver
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: primary_conninfo missing from pg_stat_wal_receiver