Re: BUG #15734: Walsender process crashing when executing SHOW ALL;

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: 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-08 07:39:03
Message-ID: 20190408073903.GJ2712@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Apr 04, 2019 at 07:54:19AM +0000, PG Bug reporting form wrote:
> I don't think that such a crash is expected behavior. Either it should
> return the table with all settings or report simply error out with message
> 'unrecognized configuration parameter "ALL"'.

No, it's not correct to just disallow ALL as we have a similar check
in GetConfigOptionByName() for individual parameters.

Problem is origically from 25fff40, and got worse as of 0c8910a0. A
superuser is able to get the list of parameters, but I can easily see
the failure when using a plain replication user. A replication user
is one which can take a full base backup, so he can easily retrieve
the full list of parameters anyway. What about bypassing the problem
and just allow WAL sender contexts to always have access to parameter
values? I don't think that this is much a security issue if one
thinks about the access to BASE_BACKUP.
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Amit Langote 2019-04-08 08:18:48 Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed
Previous Message Amit Langote 2019-04-08 07:21:47 Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed