Date: Wed, 10 Apr 2019 11:01:21 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: cyberdemn@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15734: Walsender process crashing when executing SHOW ALL;
Message-ID: <20190410150121.GA26340@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20190410060427.GB2728@paquier.xyz>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On 2019-Apr-10, Michael Paquier wrote:

> After pondering more about this one, allowing replication to have the
> same rights as a superuser in this case does not feel completely right
> either as this is just a shortcut to bypass the syscache lookups
> happening through is_member_of_role().  So attached is a much better
> and simple idea: let's just use a transaction context when issuing the
> SHOW command so as it is possible to perform cache lookups correctly.
> This way, even a replication role is not able to see some parameters
> except if the role is a member of pg_read_all_settings, which is more
> consistent.
> 
> This needs a backpatch down to v10.

Thanks for tracking this down.

I think we should have a few tests issuing SHOW ALL in a replication
connection with various levels of privilege; it's annoying that this bug
took two years to find.  With that, special-purpose buildfarm members
would tell us if we've made some mistake in transaction handling or
whatever.

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