On 2021/03/22 17:49, Kyotaro Horiguchi wrote:
At Mon, 22 Mar 2021 14:07:43 +0900, Fujii Masao
wrote in
On 2021/03/22 14:03, shinya11.k...@nttdata.com wrote:
Barring any objection, I will commit this.
I think it's good except for a typo "thoes four bits"
Thanks for the review!
At Mon, 22 Mar 2021 14:07:43 +0900, Fujii Masao
wrote in
>
>
> On 2021/03/22 14:03, shinya11.k...@nttdata.com wrote:
> >> Barring any objection, I will commit this.
> >I think it's good except for a typo "thoes four bits"
>
> Thanks for the review! Attached is the updated version of the
On 2021/03/22 14:03, shinya11.k...@nttdata.com wrote:
Barring any objection, I will commit this.
I think it's good except for a typo "thoes four bits"
Thanks for the review! Attached is the updated version of the patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
l.com
>Subject: Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump.
>
>
>
>On 2021/03/19 18:27, Fujii Masao wrote:
>>
>>
>> On 2021/03/19 15:06, shinya11.k...@nttdata.com wrote:
>>>>>> But 0 value maybe looks strange, so in current versi
On 2021/03/19 18:27, Fujii Masao wrote:
On 2021/03/19 15:06, shinya11.k...@nttdata.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 (%)
- --- --- --- --- - --- ...
On 2021/03/19 15:06, shinya11.k...@nttdata.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)
>>>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)
On 1/7/21 2:55 AM, shinya11.k...@nttdata.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) - (
>Thanks for review, and sorry for reply so later.
>
>>I reviewed the patch and found some problems.
>>>+ if(startSegNo != endSegNo)
>>>+ else if(record->ReadRecPtr / XLOG_BLCKSZ !=
>>>+ if(rmid == RM_XLOG_ID && info == XLOG_SWITCH)
>>>+ if(ri == RM_XLOG_ID)
>>>+ if(info == XLOG_SWITCH)
>>You need
Thanks for review, and sorry for reply so later.
>I reviewed the patch and found some problems.
>>+ if(startSegNo != endSegNo)
>>+ else if(record->ReadRecPtr / XLOG_BLCKSZ !=
>>+ if(rmid == RM_XLOG_ID && info == XLOG_SWITCH)
>>+ if(ri == RM_XLOG_ID)
>>+ if(info == XLOG_SWITCH)
>You need to put a
Thanks for the reply. > Mr.Horiguchi.
I reviewed the patch and found some problems.
>+ if(startSegNo != endSegNo)
>+ else if(record->ReadRecPtr / XLOG_BLCKSZ !=
>+ if(rmid == RM_XLOG_ID && info == XLOG_SWITCH)
>+ if(ri == RM_XLOG_ID)
>+ if(info == XLOG_SWITCH)
You need to put a space after the
Thanks for taking a look on this.
At Fri, 4 Dec 2020 04:20:47 +, wrote in
> When I execute pg_waldump, I found that XLOG/SWITCH_JUNK appears twice.
> Is this problem solved by the way of correcting the previously discussed
> Transaction/COMMIT?
>
> $ ../bin/pg_waldump --stats=record
When I execute pg_waldump, I found that XLOG/SWITCH_JUNK appears twice.
Is this problem solved by the way of correcting the previously discussed
Transaction/COMMIT?
$ ../bin/pg_waldump --stats=record ../data/pg_wal/00010001
Type N
>It looks to me "We can know that length by subtracting the LSN of
>XLOG_SWITCH from the next record's LSN so it doesn't add any
>information."
Sorry,maybe I miss this before.
But I think it will be better to show it clearly.
>So the length of in this case is:
>
>LOC(SEG A+1) - ReadRecPtr -
At Fri, 16 Oct 2020 16:21:47 +0800, "movead...@highgo.ca"
wrote in
> Thanks for all the suggestion, and new patch attached.
>
> >Andres suggested that we don't need that description with per-record
> >basis. Do you have a reason to do that? (For clarity, I'm not
> >suggesting that you should
Thanks for all the suggestion, and new patch attached.
>Andres suggested that we don't need that description with per-record
>basis. Do you have a reason to do that? (For clarity, I'm not
>suggesting that you should reving it.)
I think Andres is saying if we just log it in xlog_desc() then we
Thanks for all the suggestions.
>Yeah. In its current shape, it means that only pg_waldump would be
>able to know this information. If you make this information part of
>xlogdesc.c, any consumer of the WAL record descriptions would be able
>to show this information, so it would provide a
At Thu, 15 Oct 2020 17:32:10 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Thu, 15 Oct 2020 12:56:02 +0800, "movead...@highgo.ca"
> wrote in
> > Thanks for all the suggestions.
> >
> > >Yeah. In its current shape, it means that only pg_waldump would be
> > >able to know this information.
At Thu, 15 Oct 2020 12:56:02 +0800, "movead...@highgo.ca"
wrote in
> Thanks for all the suggestions.
>
> >Yeah. In its current shape, it means that only pg_waldump would be
> >able to know this information. If you make this information part of
> >xlogdesc.c, any consumer of the WAL record
At Wed, 14 Oct 2020 13:46:13 -0700, Andres Freund wrote in
> Hi,
>
> On 2020-10-14 15:52:43 +0900, Michael Paquier wrote:
> > Yeah. In its current shape, it means that only pg_waldump would be
> > able to know this information. If you make this information part of
> > xlogdesc.c, any consumer
Hi,
On 2020-10-14 15:52:43 +0900, Michael Paquier wrote:
> Yeah. In its current shape, it means that only pg_waldump would be
> able to know this information. If you make this information part of
> xlogdesc.c, any consumer of the WAL record descriptions would be able
> to show this information,
On Wed, Oct 14, 2020 at 10:29:44AM +0900, Kyotaro Horiguchi wrote:
> The reason is the function XLogDumpRecordLen is a common function
> among all kind of LOG records, not belongs only to XLOG_SWICH. And the
> junk_len is not useful for other than XLOG_SWITCH. Descriptions
> specifc to
At Mon, 12 Oct 2020 09:46:37 +0800, "movead...@highgo.ca"
wrote in
>
> Thanks for reply.
>
> >If you wish to add more information about a XLOG_SWITCH record, I
> >don't think that changing the signature of XLogDumpRecordLen() is
> >adapted because the record length of this record is defined
Thanks for reply.
>If you wish to add more information about a XLOG_SWITCH record, I
>don't think that changing the signature of XLogDumpRecordLen() is
>adapted because the record length of this record is defined as
>Horiguchi-san mentioned upthread, and the meaning of junk_len is
>confusing
On Sat, Oct 10, 2020 at 09:50:02AM +0800, movead...@highgo.ca wrote:
>> I think that the length of the XLOG_SWITCH record is no other than 24
>> bytes. Just adding the padding? garbage bytes to that length doesn't
>> seem the right thing to me.
>
> Here's the lookes:
> rmgr: XLOGlen
>I think that the length of the XLOG_SWITCH record is no other than 24
>bytes. Just adding the padding? garbage bytes to that length doesn't
>seem the right thing to me.
>
>If we want pg_waldump to show that length somewhere, it could be shown
>at the end of that record explicitly:
>
>rmgr: XLOG
At Fri, 9 Oct 2020 13:41:25 +0800, "movead...@highgo.ca"
wrote in
> Hello hackers,
>
> We know that pg_waldump can statistics size for every kind of records. When I
> use
> the feature I find it misses some size for XLOG_SWITCH records. When a user
> does
> a pg_wal_switch(), then postgres
Hello hackers,
We know that pg_waldump can statistics size for every kind of records. When I
use
the feature I find it misses some size for XLOG_SWITCH records. When a user does
a pg_wal_switch(), then postgres will discard the remaining size in the current
wal
segment, and the pg_waldump tool
28 matches
Mail list logo
