Re: Failing to known state - Mailing list pgsql-general

From oleg yusim
Subject Re: Failing to known state
Date
Msg-id CAKd4e_GPEgqLE01_H4+9q1BkkayA1NY5uKFSWd9shGxUYFDTgw@mail.gmail.com
Whole thread Raw
In response to Re: Failing to known state  (Adrian Klaver <adrian.klaver@aklaver.com>)
List pgsql-general
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.klaver@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.klaver@aklaver.com

pgsql-general by date:

Previous
From: Jim Nasby
Date:
Subject: Re: COPY FROM STDIN
Next
From: John R Pierce
Date:
Subject: Re: Code of Conduct: Is it time?