On 14/10/2025 11:11, Andrei Lepikhov wrote:
> For me, the ideal place for such a hook is CheckPointGuts, right between
> the CheckPointBuffers call and fsyncs. I think that to demonstrate how
> this hook can work, the pg_stat_statements storage may need to be
> redesigned slightly.
There are two patches: 0001, which is the checkpoint hook itself, and
0002, which includes an example and a trivial test.
During development, I attempted to apply it in my different modules and
realised that the hook is preferred over an RMGR callback - I don't
actually want to be forced to register RMGR in each project and have it
loadable on an instance startup. In lightweight modules, I want to keep
my knowledge base relatively close to the current state of the instance.
Nevertheless, the plan freezing extension (for example) needs to ensure
that the user's query plan is 'frozen' after the function call.
Therefore, we need to store the decision made in the WAL, which requires
dumping the state into a file before performing the WAL cut.
Additionally, I'd like to experiment with synchronising an extension
state between master and replica through WAL records, as most
optimisation recommendations are relevant to both instances.
Patch 0001 contains a hook that is called once after all checkpoint
preparations have finished. I recall that people mentioned it might be
helpful for AMs as well - feel free to propose changes to this patch.
Patch 2 adds an example to the test_dsm_registry module, as it is
precisely the way I write the code: named DSM segment -> shared HTAB ->
file dump. So, it looks natural and opens a room to extend this example
by employing RMGR and xact callbacks to keep the extension state as
close to the committed changes as possible.
The test looks pretty trivial so far - feel free to propose ideas on how
to extend it.
--
regards, Andrei Lepikhov,
pgEdge
