Re: primary_conninfo missing from pg_stat_wal_receiver
От | Michael Paquier |
---|---|
Тема | Re: primary_conninfo missing from pg_stat_wal_receiver |
Дата | |
Msg-id | CAB7nPqReWixXN19MUJwpz4W3SPVR9yn6D+L1aqX229w02ohmXg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: primary_conninfo missing from pg_stat_wal_receiver (Fujii Masao <masao.fujii@gmail.com>) |
Список | 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 по дате отправления: