Re: Doing authentication in backend

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Doing authentication in backend
Date: 2001-06-14 20:49:35
Message-ID: 21706.992551775@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> Also note that we could easily fix things so that the max-number-of-
>> backends limit is not checked until we have passed the authentication
>> procedure. A PM child that's still busy authenticating doesn't have
>> to count.

> How does the postmaster know? And if the postmaster does get to know,
> what does it do with children it has "accidentally" allowed in excess?

The postmaster doesn't have to know, nor should it be in the business of
enforcing the MaxBackends limit. It should just spawn off children
(though maybe we should put a limit on total children, somewhat higher
than MaxBackends, as a crude form of preventing runaway resource usage
under a DOS attack).

A spawned child will first proceed with the authorization cycle; if it
fails, it just exits. If it succeeds, it will then try to become a
backend. When it tries to insert an entry into the PROC array, if
there's not an available slot then you lose (send "too many clients"
failure message to client, and exit). We might have to reorganize the
code a little bit so that this exit happens cleanly before anything else
is done to shared memory, but it's surely doable.

The PM itself has no real need to distinguish children that are active
backends from those that are still doing authentication, AFAICS.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Doug McNaught 2001-06-14 20:58:33 Re: What (not) to do in signal handlers
Previous Message Peter Eisentraut 2001-06-14 20:34:08 Re: Doing authentication in backend