From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Robins Tharakan <tharakan(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allow pg_dumpall to work without pg_authid |
Date: | 2017-02-28 17:49:05 |
Message-ID: | CANP8+jLk4cmX4MjhpvrLsGwYqiJ_EdtSh8EF85hJin1WBYfp5g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 28 February 2017 at 16:12, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Robert,
>
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> On Sun, Feb 19, 2017 at 12:24 AM, Robins Tharakan <tharakan(at)gmail(dot)com> wrote:
>> > I would like to work on a patch to accommodate restricted environments (such
>> > as AWS RDS Postgres) which don't allow pg_authid access since their
>> > definition of Superuser is just a regular user with extra permissions.
>> >
>> > Would you consider a patch to add a flag to work around this restriction,
>> > Or, do you prefer that this be maintained outside core?
>>
>> I am a little surprised that this patch has gotten such a good
>> reception. We haven't in the past been all that willing to accept
>> core changes for the benefit of forks of PostgreSQL; extensions, sure,
>> but forks? Maybe we should take the view that Amazon has broken this
>> and Amazon ought to fix it, rather than making it our job to (try to)
>> work around their bugs.
>
> I suspect it's gotten a reasonably good reception because it's about
> making it possible to do more things as a non-superuser, which is
> something that we've got a number of different people working on
> currently, with two interesting patches from Dave geared towards doing
> that for monitoring. I have no doubt that there will be other users of
> this, which means that it isn't "for the benefit of forks" but for users
> of core too.
If this was of benefit only to one company it would not get time or
attention from me. I thought that would have been obvious enough, but
if not, I'm happy to say it clearly.
The enhanced patch by me removes any mention of specific vendors or approaches.
I've edited the stated reason for the patch on the CF app, so its
clearer as to why this might be acceptable.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-02-28 17:54:58 | Re: avoid bloat from CREATE INDEX CONCURRENTLY |
Previous Message | Andres Freund | 2017-02-28 17:46:13 | Re: Performance degradation in TPC-H Q18 |