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
>

Reply via email to