Re: primary_conninfo missing from pg_stat_wal_receiver

Fujii Masao wrote:
> On Thu, Jun 30, 2016 at 6:01 AM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
> > Alvaro Herrera wrote:
> >
> >> I propose to push this patch, closing the open item, and you can rework
> >> on top -- I suppose you would completely remove the original conninfo
> >> from shared memory and instead only copy the obfuscated version there
> >> (and probably also remove the ready_to_display flag). I think we'd need
> >> to see the patch before deciding whether we want it in 9.6 or not,
> >> keeping in mind that having the conninfo in shared memory is a
> >> pre-existing problem, unrelated to the pgstats view new in 9.6.
> >
> > Pushed this.
>
> Thanks for pushing the patch!
> But I found two problems in the patch you pushed.
>
> (1)
> ready_to_display flag must be reset to false when walreceiver dies.
> Otherwise, pg_stat_wal_receiver can report the password (i.e.,
> the problem that I reported upthread can happen) when walreceiver restarts
> because ready_to_display flag is true from the beginning in that case.
> But you forgot to reset the flag to false when walreceiver dies.

Oops, you're right, since it's in shmem it doesn't get reset in the new
process. Will fix.

> (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.

Yeah, I thought that was OK.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services