From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | cyberdemn(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15734: Walsender process crashing when executing SHOW ALL; |
Date: | 2019-04-10 15:01:21 |
Message-ID: | 20190410150121.GA26340@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-04-10 15:45:28 | Re: BUG #15744: Replication slot peak query throwing error for wrong sequence entry for toast chunk |
Previous Message | Peter Eisentraut | 2019-04-10 08:28:55 | Re: BUG #15744: Replication slot peak query throwing error for wrong sequence entry for toast chunk |