| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | Lukas Fittl <lukas(at)fittl(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Ahmed Gouda <gouda0x(at)gmail(dot)com>, Bernd Reiß <bd_reiss(at)gmx(dot)at> |
| Subject: | Re: Fix cumulative WAL statistics double-counting from parallel workers |
| Date: | 2026-11-02 09:32:18 |
| Message-ID: | auhYonSPeCx8cZ4u@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Nov 02, 2026 at 08:41:15AM +0000, Bertrand Drouvot wrote:
> On Mon, Nov 02, 2026 at 05:16:29PM +0900, Michael Paquier wrote:
>> If I am reading the patch right, it means that a leader's pgWalUsage
>> includes both its own activity *and* the activity of its workers. It
>> sounds to me like a mistake to do that. Why aren't pgWalUsage and
>> friends handled in such a way that they only include the activity of
>> their own process?
>
> Wouldn't that change the semantics of pgWalUsage for out of core extensions using
> it (if any) the same way as PGSS? We can adjust PGSS, but those extensions would
> start seeing leader only activity once running a version with this change?
We don't have to change the meaning of pgWalUsage in the stable
branches. We could keep it there, where I'd suggest to invent a third
WalUsage then that aggregates only the data of its own. Then, we use
the "own" WalUsage for the stats, and for the combined view use the
"own" WalUsage and pgWalUsageFromWorkers. Finally, remove all traces
of pgWalUsage from the backend code, remove its definition on HEAD.
Perhaps the last point is not required.
My point is that I don't get the meaning of these new
WalUsageAccumDiff(), especially as we could design things so as we
avoid them.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Bertrand Drouvot | 2026-11-02 09:30:48 | Re: Setting the number of digits after the decimal point with a psql's pset variable |