Re: Higher level questions around shared memory stats

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Higher level questions around shared memory stats
Дата
Msg-id 20220401051225.qv2vzp45ktkqiuqq@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Higher level questions around shared memory stats  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: Higher level questions around shared memory stats  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
Hi,

On 2022-03-31 20:06:07 -0700, David G. Johnston wrote:
> Do we really think no one has taken our advice in the documentation and
> moved their stats_temp_directory to a RAM-based file system?

I'm pretty sure some have, I've seen it in the field in the past.


> The question is whether current uses of PG_STAT_TMP_DIR can be made to use
> the value of the GUC without them knowing or caring about the fact we
> changed PG_STAT_TMP_DIR from a static define for pg_stat_tmp to whatever
> the current value of stats_temp_directory is.  I take it from the compiler
> directive of #define that this isn't doable.

Correct, we can't.


> If we later want to coerce extensions (and even our own code) to use a
> user-supplied directory we can then remove the define and give them an API
> to use instead.

FWIW, it's not quite there yet (as in, not a goal for 15), but with a bit
further work, a number of such extensions could use the shared memory stats
interface to store their additional stats. And they wouldn't have to care
about where the files get stored.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: logical decoding and replication of sequences
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: unnecessary (same) restart_lsn handing in LogicalIncreaseRestartDecodingForSlot