Re: primary_conninfo missing from pg_stat_wal_receiver

Fujii Masao wrote:
> On Thu, Jun 30, 2016 at 6:01 AM, Alvaro Herrera
> <alvherre@2ndquadrant.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