Hi Adrian, Thank you very much for that link. It confirms what JD and John said, plus explains couple other moments to me.
Thanks, Oleg On Tue, Jan 5, 2016 at 7:04 PM, Adrian Klaver <adrian.kla...@aklaver.com> wrote: > On 01/05/2016 04:12 PM, oleg yusim wrote: > > Hi Adrian, > > > > I meant a scenario, when user is trying to connect to database (doesn't > > matter what interface) and database fails at this moment. If all > > authentication/authorization/validation functions are written to return > > false in case of abnormal termination, we are fine. If not, we can > > potentially encounter the situation when database fails into state where > > user is given greater privileges than he/she should or even > > authenticated, when he/she shouldn't. > > Might want to take a look at: > > > http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/postmaster/postmaster.c;h=41dbdf4bf9eeb54ae0a774ab21fc1c1362aa55f9;hb=d25c7d70ff46d1b2f2400f29d100190efe84d70d > > /* > * CleanupBackend -- cleanup after terminated backend. > * > * Remove all local state associated with backend. > * > * If you change this, see also CleanupBackgroundWorker. > */ > static void > CleanupBackend > > > /* > * HandleChildCrash -- cleanup after failed backend, bgwriter, > checkpointer, > * walwriter, autovacuum, or background worker. > * > * The objectives here are to clean up our local state about the child > * process, and to signal all other remaining children to quickdie. > */ > static void > HandleChildCrash(in > > etc > > Just do a find on crash. > > > > > > Thanks, > > > > Oleg > > > > > > -- > Adrian Klaver > adrian.kla...@aklaver.com >
