Re: Comments on Custom RMGRs

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Comments on Custom RMGRs
Дата
Msg-id beb9c43d6492ffc273d236e4b93270dfad035f2f.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Comments on Custom RMGRs  (Danil Anisimow <anisimow.d@gmail.com>)
Ответы Re: Comments on Custom RMGRs  (Danil Anisimow <anisimow.d@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Refactor SASL exchange in preparation for OAuth Bearer
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Comments on Custom RMGRs