From: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-patches(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] TODO Done. Superuser backend slot reservations |
Date: | 2002-08-26 10:36:10 |
Message-ID: | Pine.LNX.4.21.0208261055020.576-100000@ponder.fairway2k.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Mon, 26 Aug 2002, Tom Lane wrote:
> "Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)uk> writes:
> > + if (!superuser() && MyBackendId > MaxBackends - ReservedBackends)
> > + elog(ERROR, "Normal user limit exceeded");
>
> This coding is wrong on its face: the slot number you happen to find has
> no relationship to the number of slots remaining free, except as an
> existence proof that the number of slots free was > 0 before you took
> one.
Yes.
I was taking the line that the last slots in the array are reserved. Those are
not going to be taken by non su connections. Therefore, if MyBackendId is
under the lower limit it doesn't matter if it's the only slot free since the
'safety' measure has already been used in restricting access to the last free
slots and it just so happens that those sessions are still active.
I take Neil's point about the order of the tests. That's my stupidity when
rearranging stuff after noticing in tests that the user information wasn't
available where I was [also stupidly] expecting it to be first time around.
--
Nigel J. Andrews
From | Date | Subject | |
---|---|---|---|
Next Message | Sir Mordred The Traitor | 2002-08-26 12:35:44 | @(#)Mordred Labs advisory 0x0006: Two minor DoS conditions in PostgreSQL |
Previous Message | Christopher Kings-Lynne | 2002-08-26 10:21:04 | Re: PostgreSQL 7.2.2 and docs |
From | Date | Subject | |
---|---|---|---|
Next Message | Pierre-Yves LANDURE | 2002-08-26 13:11:54 | Polygons Utils Contrib |
Previous Message | Alvaro Herrera | 2002-08-26 09:28:21 | Re: [HACKERS] pg_attribute.attisinherited ? |