Allowing dsm allocations in single user mode

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Allowing dsm allocations in single user mode
Дата
Msg-id 20210403232942.c5ddlvc2pvgtpfqz@alap3.anarazel.de
обсуждение исходный текст
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Confusing behavior of psql's \e
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: ALTER TABLE ADD COLUMN fast default