From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add statistics to pg_stat_wal view for wal related parameter tuning |
Date: | 2020-12-22 00:39:35 |
Message-ID: | 20201222003935.47aoxfmokltlrlf2@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2020-12-21 13:16:50 -0800, Andres Freund wrote:
> On 2020-12-02 13:52:43 +0900, Fujii Masao wrote:
> > Pushed. Thanks!
>
> Why are wal_records/fpi long, instead of uint64?
> long wal_records; /* # of WAL records produced */
> long wal_fpi; /* # of WAL full page images produced */
> uint64 wal_bytes; /* size of WAL records produced */
>
> long is only 4 byte e.g. on windows, and it is entirely possible to wrap
> a 4 byte record counter. It's also somewhat weird that wal_bytes is
> unsigned, but the others are signed?
>
> This is made doubly weird because on the SQL level you chose to make
> wal_records, wal_fpi bigint. And wal_bytes numeric?
Some more things:
- There's both PgStat_MsgWal WalStats; and static PgStat_WalStats walStats;
that seems *WAY* too confusing. And the former imo shouldn't be
global.
- AdvanceXLInsertBuffer() does WalStats.m_wal_buffers_full, but as far
as I can tell there's nothing actually sending that?
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | tsunakawa.takay@fujitsu.com | 2020-12-22 00:53:15 | RE: libpq debug log |
Previous Message | Bruce Momjian | 2020-12-21 22:17:52 | Re: Proposed patch for key managment |