From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, lukas(at)fittl(dot)com |
Subject: | Re: WAL-logging facility for pgstats kinds |
Date: | 2025-01-09 04:53:48 |
Message-ID: | Z39WXDupHUl4GLWy@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 02, 2025 at 08:08:42PM -0500, Andres Freund wrote:
> I can't think of a real case where we would want to WAL log the stats
> themselves, rather than re-emitting stats during replay based on the WAL
> record of the "underlying object".
>
> Do you have counter-examples?
I'm not sure if the rebuild based on the WAL records is simpler than
logging a snapshot of them that the startup process could digest.
Anyway, I've also wanted to be able to replicate stats for historical
tracking for stats logged through hooks, and a second case was
injection point stats. All these would require registering a custom
rmgr on top of a custom stats kind, and centralizing the logic eases a
lot some of the sanity checks they'd require as the redo callback of a
stats kind can just be attached to its PgStat_KindInfo.
I know that Lucas has been playing a bit with the area, and perhaps
he has more cases in mind where the replication of stats data could be
relevant. So I am adding him in CC. Perhaps I could be wrong, of
course.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Lakhin | 2025-01-09 05:00:01 | Re: Several buildfarm animals fail tests because of shared memory error |
Previous Message | Michael Paquier | 2025-01-09 04:03:15 | Re: per backend WAL statistics |