Re: Comments on Custom RMGRs - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Comments on Custom RMGRs
Date
Msg-id beb9c43d6492ffc273d236e4b93270dfad035f2f.camel@j-davis.com
Whole thread Raw
In response to Re: Comments on Custom RMGRs  (Danil Anisimow <anisimow.d@gmail.com>)
Responses Re: Comments on Custom RMGRs
List pgsql-hackers
On Thu, 2024-03-21 at 19:47 +0700, Danil Anisimow wrote:
> [pgss_001.v1.patch] adds a custom resource manager to the
> pg_stat_statements extension.

Did you consider moving the logic for loading the initial contents from
disk from pgss_shmem_startup to .rmgr_startup?

> The rm_checkpoint hook allows saving shared memory data to disk at
> each checkpoint. However, for pg_stat_statements, it matters when the
> checkpoint occurred. When the server shuts down, pgss deletes the
> temporary file of query texts. In other cases, this is unacceptable.
> To provide this capability, a flags parameter was added to the
> rm_checkpoint hook. The changes are presented in [rmgr_003.v2.patch].

Overall this seems fairly reasonable to me. I think this will work for
similar extensions, where the data being stored is independent from the
buffers.

My biggest concern is that it might not be quite right for a table AM
that has complex state that needs action to be taken at a slightly
different time, e.g. right after CheckPointBuffers().

Then again, the rmgr is a low-level API, and any extension using it
should be prepared to adapt to changes. If it works for pgss, then we
know it works for at least one thing, and we can always improve it
later. For instance, we might call the hook several times and pass it a
"phase" argument.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Refactor SASL exchange in preparation for OAuth Bearer
Next
From: Jeff Davis
Date:
Subject: Re: Comments on Custom RMGRs