From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Shinya11(dot)Kato(at)nttdata(dot)com, david(at)pgmasters(dot)net, movead(dot)li(at)highgo(dot)ca |
Cc: | pgsql-hackers(at)postgresql(dot)org, andres(at)anarazel(dot)de, michael(at)paquier(dot)xyz, ahsan(dot)hadi(at)highgo(dot)ca, horikyota(dot)ntt(at)gmail(dot)com |
Subject: | Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump. |
Date: | 2021-03-22 02:22:07 |
Message-ID: | 790571f2-7068-3717-6223-85683db74542@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021/03/19 18:27, Fujii Masao wrote:
>
>
> On 2021/03/19 15:06, Shinya11(dot)Kato(at)nttdata(dot)com wrote:
>>>>> But 0 value maybe looks strange, so in current version I show it like >below:
>>>>> Type N (%) Record size (%) FPI size (%) Combined size (%)
>>>>> ---- - --- ----------- --- -------- --- ------------- --- ...
>>>>> XLOG/SWITCH_JUNK - ( -) 11006248 ( 72.26) - ( -) 11006248 ( 65.78)
>>>>> Transaction/COMMIT 10 ( 0.03) 340 ( 0.00) 0 ( 0.00) 340 ( 0.00)
>>>>
>>>> I just wanted to know why the "count" and "fpi_len" fields 0 are.
>>>> So, it would be nice to have 0 values. Sorry for confusing you.
>>>
>>> Kato, it's not clear to me if you were asking for - to be changed back to 0?
>>>
>>> You marked the patch as Ready for Committer so I assume not, but it would be
>>> better to say clearly that you think this patch is ready for a committer to look at.
>>
>> Yes, I don't think it needs to be changed back to 0.
>> I think this patch is ready for a committer to look at.
>
> What's the use case of this feature? I read through this thread briefly,
> but I'm still not sure how useful this feature is.
>
> Horiguchi-san reported one issue upthread; --stats=record shows
> two lines for Transaction/COMMIT record. Probably this should be
> fixed separately.
>
> Horiguchi-san,
> Do you have updated version of that bug-fix patch?
> Or you started another thread for that issue?
I confirmed that only XACT records need to be processed differently.
So the patch that Horiguchi-san posted upthread looks good and enough
to me. I added a bit more detail information into the comment in the patch.
Attached is the updated version of the patch. Since this issue looks like
a bug, I'm thinking to back-patch that. Thought?
Barring any objection, I will commit this.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Attachment | Content-Type | Size |
---|---|---|
fix_pg_waldump_xact_commit_record_stats_fujii.patch | text/plain | 799 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-03-22 02:27:15 | Re: replication cleanup code incorrect way to use of HTAB HASH_REMOVE ? |
Previous Message | Euler Taveira | 2021-03-22 02:15:10 | Re: row filtering for logical replication |