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
Re: primary_conninfo missing from pg_stat_wal_receiver |
Список | 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 по дате отправления: