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