On Mon, Nov 21, 2022 at 5:30 PM Adrian Klaver
wrote:
> On 11/21/22 15:05, Bryn Llewellyn wrote:
> >
> > In fact, David Johnston did unequivocally challenge my strawman a couple
> of turns back, thus:
> >
>
>
> And the equivocal additions later in the post:
>
Yeah, even when I try to be
On 11/21/22 15:05, Bryn Llewellyn wrote:
adrian.kla...@aklaver.com wrote:
...why the "Nobody supports it!" statement for a recommendation that only
appeared at the same time? I for one have a poor record of mind reading and/or predicting
the future:)
Here’s what I wrote in the post that
On 22 Nov 2022, at 10:05, Bryn Llewellyn wrote:
> Because PG allows a cluster to have as many superusers as you please, and
> because any one of these can create or drop another, any convention in this
> space needs some extra mechanisms to enforce it..
>
> … effectively tamper-proof
On Mon, Nov 21, 2022 at 4:05 PM Bryn Llewellyn wrote:
>
> I believe that the fact that a superuser's ability to start a session can
> be limited by what the "hba_file" says is critical here—together with the
> fact that the ability to edit this file is governed by the regime of O/S
> users and
> adrian.kla...@aklaver.com wrote:
>
>> b...@yugabyte.com wrote:
>>
>> Consider this wording. It also uses “good practice”.
>>
>> «
>> It is good practice to limit the number of superuser roles that exist in a
>> cluster to exactly one: the inevitable bootstrap superuser. This recognizes
>>
On 11/21/22 11:46, Bryn Llewellyn wrote:
Nobody supports it!
I went back through the thread and don't anywhere when you made the
above statement, correct me if I am wrong. In that case there was
nothing to support or not support until now. What people where
responding to the title of the
> adrian.kla...@aklaver.com wrote:
>
>> b...@yugabyte.com:
>>
>> Consider this wording. It also uses “good practice”.
>> «
>> It is good practice to limit the number of superuser roles that exist in a
>> cluster to exactly one: the inevitable bootstrap superuser. This recognizes
>> the fact
On Mon, Nov 21, 2022 at 10:40 AM Bryn Llewellyn wrote:
>
> Consider this wording. It also uses “good practice”.
>
> «
> It is good practice to limit the number of superuser roles that exist in a
> cluster to exactly one: the inevitable bootstrap superuser. This recognizes
> the fact that, once
On 11/21/22 9:40 AM, Bryn Llewellyn wrote:
adrian.kla...@aklaver.com wrote:
Then there’s this (from the doc):
It is good practice to create a role that has the CREATEDB and CREATEROLE
privileges, but is not a superuser, and then use this role for all routine
management of databases and
> adrian.kla...@aklaver.com wrote:
>
>> karsten.hilb...@gmx.net:
>>
>>> adrian.kla...@aklaver.com wrote:
>>>
b...@yugabyte.com
Thanks to all who offered their views on my question. It seems that
different people will reach different conclusions. I’ll take this as
On 11/20/22 17:48, Bryn Llewellyn wrote:
hjp-pg...@hjp.at wrote:
ronljohnso...@gmail.com wrote:
[developers or devops folks] like to "fix" things without documenting what they
did, and then, when
something breaks, denying they did anything (or honestly not believing that
whatever "trivial"
On Sun, Nov 20, 2022 at 6:48 PM Bryn Llewellyn wrote:
> I haven’t seen anything in the PG doc that warns against creating
> additional superusers—so I suppose that this fact tells me something.
> Nevertheless, I remain convinced about what I’d recommend here:
>
> The default choice must be to
> hjp-pg...@hjp.at wrote:
>
>> ronljohnso...@gmail.com wrote:
>>
>> [developers or devops folks] like to "fix" things without documenting what
>> they did, and then, when
>> something breaks, denying they did anything (or honestly not believing that
>> whatever "trivial" thing they did could
On 2022-11-18 16:21:18 -0600, Ron wrote:
> On 11/18/22 16:13, Peter J. Holzer wrote:
> > So you can give these credentials to you developers or devops folks
> > (whom you trust not attack the system -
>
> They like to "fix" things without documenting what they did, and then, when
> something
On 11/18/22 15:08, Peter J. Holzer wrote:
On 2022-11-17 11:36:15 -0800, Bryn Llewellyn wrote:
The detail below leads to a simply stated question:
Given that the bootstrap superuser must exist, is there ever a reason to create
another role with "superuser"?
My intuition tells me that the
On 11/18/22 16:13, Peter J. Holzer wrote:
[snip]
So you can give these credentials to you developers or devops folks
(whom you trust not attack the system -
They like to "fix" things without documenting what they did, and then, when
something breaks, denying they did anything (or honestly not
On 2022-11-18 13:11:24 -0800, Bryn Llewellyn wrote:
> hjp-pg...@hjp.at wrote:
> b...@yugabyte.com wrote:
> Given that the bootstrap superuser must exist, is there ever a reason
> to create
> another role with "superuser"?
>
> My intuition tells me that the
> hjp-pg...@hjp.at wrote:
>
> b...@yugabyte.com wrote:
>
>> The detail below leads to a simply stated question:
>>
>> Given that the bootstrap superuser must exist, is there ever a reason to
>> create
>> another role with "superuser"?
>>
>> My intuition tells me that the answer is a
On 2022-11-17 11:36:15 -0800, Bryn Llewellyn wrote:
> The detail below leads to a simply stated question:
>
> Given that the bootstrap superuser must exist, is there ever a reason to
> create
> another role with "superuser"?
>
> My intuition tells me that the answer is a resounding "No!".
Is
The detail below leads to a simply stated question:
Given that the bootstrap superuser must exist, is there ever a reason to create
another role with "superuser"?
My intuition tells me that the answer is a resounding "No!".
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
*Detail*
20 matches
Mail list logo
