Re: user connection not recorded? - Mailing list pgsql-general

From Adrian Klaver
Subject Re: user connection not recorded?
Date
Msg-id 55BA3B98.8040208@aklaver.com
Whole thread Raw
In response to Re: user connection not recorded?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: user connection not recorded?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On 07/30/2015 07:46 AM, Tom Lane wrote:
> Adrian Klaver <adrian.klaver@aklaver.com> writes:
>> Eventually got around to figuring that. So just for my reference, the
>> code snippet I showed from postinit.c seems to show a path where a
>> username is not used but is  substituted with BOOTSTRAP_SUPERUSERID.
>
> That's single-user mode.

Alright, but the part that has me confused is this comment in the code:

  * In standalone mode and in autovacuum worker processes, we use a fixed
  * ID, otherwise we figure it out from the authenticated user name.

and this

else if (IsBackgroundWorker)

I read the above to mean background processes also follow that path. I
have been trying to figure more about what goes on internally in
Postgres and reading the source seems the bet way to do that. Reading it
wrong is not helpful, so I would appreciate corrections to my
understanding or lack thereof.

>
>> Am I following that correctly and what is BOOTSTRAP_SUPERUSERID?
>
> BOOTSTRAP_SUPERUSERID is the OID of the precreated superuser.
>
> The reason for that hack is to ensure you can still log in, in single-user
> mode, even if you've done something stupid like "delete from pg_authid".
> You'll be running under a user OID that doesn't actually exist in
> pg_authid, but it won't matter because the code will believe you're a
> superuser and will never go looking for the missing row.  Then you
> can create yourself a new superuser, and resolve not to do that again.

Not that I ever done anything like that:)

>
>             regards, tom lane
>


--
Adrian Klaver
adrian.klaver@aklaver.com


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: user connection not recorded?
Next
From: Ramesh T
Date:
Subject: Re: instr detail