Peter Eisentraut <peter_e@gmx.net> writes:
> When the
> max_backend+1'th backend tries to register itself for the shared
> resources I get:
> NOTICE: SIBackendInit: no free procState slot available
> psql: FATAL 1: Backend cache invalidation initialization failed
> [terminates]
This was the test I alluded to as needing to be moved up.
> I'd like to catch this case earlier, to avoid having to wire in such a
> fundamental setting so deeply into the resource management. But I
> couldn't find a good interface to count the already-registered backends.
That would not do: you'd have a race condition, since there might be
free slots when you count but none by the time you want to actually
register. Checking for free slots and acquiring one has to be an atomic
operation.
I've been in that code before; if you like I'll take care of making this
part work more nicely.
> * Is it okay to ignore the count field in the password packet and read
> the actual password like a null-terminated string? That was only there
> for the postmaster way of handling incomplete packets, right?
Seems like we ought to keep the packet-parsing rules the same, to avoid
possible introduction of client compatibility problems.
> * Maybe we need to keep the "poor man's multitasking" code in the
> postmaster to allow for piecewise-arriving startup packets. Surely it
> could be simplified a lot, but I didn't bother with this yet.
Um, shouldn't collection of the startup packet be done after the fork?
I was envisioning that the top process do nothing except accept() and
fork(). So there's no need for pseudo-multitasking: you just have the
one connection to deal with in any one PM child.
regards, tom lane