Allowing dsm allocations in single user mode - Mailing list pgsql-hackers

From Andres Freund
Subject Allowing dsm allocations in single user mode
Date
Msg-id 20210403232942.c5ddlvc2pvgtpfqz@alap3.anarazel.de
Whole thread Raw
List pgsql-hackers
Hi,

Right now dsm_create() has the following assertion:
    /* Unsafe in postmaster (and pointless in a stand-alone backend). */
    Assert(IsUnderPostmaster);

I agree with the "unsafe in postmaster" bit. But I'm not convinced by
the "pointless in a stand-alone backend" part.

We're starting to build building blocks of the system using DSM now, and
several of those seem like they should work the same whether in single
user mode or not.

I just hit this when testing whether the shared memory stats support
works in single user mode: It does, as long as only a few stats exist,
after that this assertion is hit, removing the assertion solves that.

Today the stats system doesn't work in single user mode, in a weird way:
2021-04-03 16:01:39.872 PDT [3698737][not initialized][1/3:0] LOG:  using stale statistics instead of current ones
becausestats collector is not responding
 
2021-04-03 16:01:39.872 PDT [3698737][not initialized][1/3:0] STATEMENT:  select * from pg_stat_all_tables;
then proceeding to return a lot of 0s and NULLs.

I think that's not great: E.g. when hitting wraparound issues, checking
something like pg_stat_all_tables.last_vacuum seems like an entirely
reasonable thing to do.

Obviously not something we'd fix with the current stats collector
approach, but I don't think it's something we should cargo cult forward
either.

Therefore I propose replacing the assertion with something along the
lines of
Assert(IsUnderPostmaster || !IsPostmasterEnvironment);

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Confusing behavior of psql's \e
Next
From: Andrew Gierth
Date:
Subject: Re: ALTER TABLE ADD COLUMN fast default