Allowing dsm allocations in single user mode

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Allowing dsm allocations in single user mode
Date: 2021-04-03 23:29:42
Message-ID: 20210403232942.c5ddlvc2pvgtpfqz@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 because stats 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2021-04-04 00:41:24 Re: ALTER TABLE ADD COLUMN fast default
Previous Message Tom Lane 2021-04-03 21:43:57 Re: Confusing behavior of psql's \e