Re: Higher level questions around shared memory stats - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Higher level questions around shared memory stats
Date
Msg-id 20220401051225.qv2vzp45ktkqiuqq@alap3.anarazel.de
Whole thread Raw
In response to Re: Higher level questions around shared memory stats  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Higher level questions around shared memory stats  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List 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 by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: logical decoding and replication of sequences
Next
From: Amit Kapila
Date:
Subject: Re: unnecessary (same) restart_lsn handing in LogicalIncreaseRestartDecodingForSlot