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

From Adrian Klaver
Subject Re: Failing to known state
Date
Msg-id 568C6830.5000403@aklaver.com
Whole thread Raw
In response to Re: Failing to known state  (oleg yusim <olegyusim@gmail.com>)
Responses Re: Failing to known state  (oleg yusim <olegyusim@gmail.com>)
List pgsql-general
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: Michael Paquier
Date:
Subject: Re: Code of Conduct: Is it time?
Next
From: oleg yusim
Date:
Subject: Re: Failing to known state