Horton

Thread

Commits

  1. Set max_safe_fds whenever we create shared memory and semaphores.

  2. Set the stack_base_ptr in main(), not in random other places.

  1. Missing initialization steps in --check and --single modes

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-12-16T23:55:11Z

    I was experimenting today with running initdb under low-resource
situations (per nearby thread about OpenBSD), and I realized that
"postgres --check" does not provide an adequate check on whether
the specified number of semaphores can be created.  That's because
it fails to check whether we can still open a reasonable number of
files after we've opened the semaphores, and on platforms where
semaphores eat file descriptors, that matters.

The lack of field complaints about this is probably because there
are no common platforms on which we choose a semaphore implementation
that consumes FDs.  (I ran into it while checking whether modern
NetBSD supports unnamed POSIX semaphores.  Seems it does, but it
uses an FD for each one, and that results in initdb overestimating
what max_connections it can choose.)

Nonetheless, this seems not totally academic, because the same code
path is also used in --boot mode.  In that mode, our failure to call
set_max_safe_fds() will result in fd.c using a conservatively tiny
limit on the number of FDs it can have open, which probably has some
small penalty on the runtime of initdb.

While comparing bootstrap.c to postmaster.c, I also noticed that
bootstrap mode is failing to call set_stack_base().  That means that
our checks for stack overflow are inoperative in bootstrap mode,
which doesn't seem great.

The same omissions appear in PostgresSingleUserMain, meaning that
--single mode also operates with few FDs and no stack depth
protection.  That's considerably less than great.

Hence I propose the attached.  I'm leaning towards not back-patching
given that these issues seem pretty minor ... but maybe for --single
mode they're not so minor?

			regards, tom lane

  2. Re: Missing initialization steps in --check and --single modes

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-12-17T02:11:05Z

    I wrote:
> While comparing bootstrap.c to postmaster.c, I also noticed that
> bootstrap mode is failing to call set_stack_base().  That means that
> our checks for stack overflow are inoperative in bootstrap mode,
> which doesn't seem great.
> The same omissions appear in PostgresSingleUserMain, meaning that
> --single mode also operates with few FDs and no stack depth
> protection.  That's considerably less than great.

Actually ... instead of calling set_stack_base() in more places,
how about we call it in fewer?  I see no reason why we can't have
a single call site in the backend's main() function.  This ensures
across-the-board coverage without fear of future omissions, and it
gives a more consistent reference point than the existing code.
(That point will be a few bytes more conservative than what we
are doing now, but that seems fine.)

I'm very tempted to move set_stack_base() and related functions
and variables out of postgres.c altogether, except I'm not sure
where they should go.  main.c doesn't quite feel like the right
place.

See attached, which doesn't address the set_max_safe_fds() issue.
That has to run after CreateSharedMemoryAndSemaphores(), so there
probably isn't a better answer than to call it after each such call.
(I guess we could call it *in* CreateSharedMemoryAndSemaphores, but
that feels outside the charter of that function.)

			regards, tom lane