Re: user connection not recorded?
От | Adrian Klaver |
---|---|
Тема | Re: user connection not recorded? |
Дата | |
Msg-id | 55BA3B98.8040208@aklaver.com обсуждение исходный текст |
Ответ на | Re: user connection not recorded? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: user connection not recorded?
|
Список | 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 по дате отправления: