| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Danil Anisimow <anisimow(dot)d(at)gmail(dot)com>, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Comments on Custom RMGRs |
| Date: | 2024-02-26 19:55:58 |
| Message-ID: | 0892cd00635c8bcd458de6d43d31cf61953da1b2.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2024-02-26 at 23:29 +0700, Danil Anisimow wrote:
> Hi,
>
> The checkpoint hook looks very useful, especially for extensions that
> have their own storage, like pg_stat_statements.
> For example, we can keep work data in shared memory and save it only
> during checkpoints.
> When recovering, we need to read all the data from the disk and then
> repeat the latest changes from the WAL.
Let's pick this discussion back up, then. Where should the hook go?
Does it need to be broken into phases like resource owners? What
guidance can we provide to extension authors to use it correctly?
Simon's right that these things don't need to be 100% answered for
every hook we add; but I agree with Andres and Robert that this could
benefit from some more discussion about the details.
The proposal calls the hook right after CheckPointPredicate() and
before CheckPointBuffers(). Is that the right place for the use case
you have in mind with pg_stat_statements?
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-02-26 20:02:20 | Better error messages for %TYPE and %ROWTYPE in plpgsql |
| Previous Message | Matthias van de Meent | 2024-02-26 19:30:56 | Re: Detoasting optionally to make Explain-Analyze less misleading |