Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump. - Mailing list pgsql-hackers
From | Kyotaro Horiguchi |
---|---|
Subject | Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump. |
Date | |
Msg-id | 20201016.180033.217520066292592870.horikyota.ntt@gmail.com Whole thread Raw |
In response to | Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump. ("movead.li@highgo.ca" <movead.li@highgo.ca>) |
List | pgsql-hackers |
At Fri, 16 Oct 2020 16:21:47 +0800, "movead.li@highgo.ca" <movead.li@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 reving it.) > I think Andres is saying if we just log it in xlog_desc() then we can not get > the result for '--stats=record' case. And the patch solve the problem. Mmm. > and > for that including it in the record description is useless. When looking > at plain records the length is sufficiently deducable by looking at the > next record's LSN. 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." > >+ XLByteToSeg(record->EndRecPtr - 1, endSegNo, record->segcxt.ws_segsize); > >We use XLByteToPrevSeg instead for this purpose. > Thanks and follow the suggestion. > > >You forgot to add a correction for short headers. > Infact, we need to consider this matter when the remain size of a wal > segment can not afford a XLogRecord struct for XLOG_SWITCH. > It's mean that if record->ReadRecPtr is on A wal segment, then > record->EndRecPtr is on (A+2) wal segment. So we need to minus > the longpagehead size on (A+1) wal segment. > In my thought we need not to care the short header, if my understand > is wrong? Maybe. When a page doesn't have sufficient space for a record, the record is split into to pieces and the last half is recorded after the header of the next page. If it next page is in the next segment, the header is a long header and a short header otherwise. If it were the last page of a segment, ReadRecPtr v <--- SEG A ------->|<---------- SEG A+1 ----------------->|<-SEG A+2 <XLOG_SWITCH_FIRST>|<LONG HEADER><XLOG_SWTICH_LAST><EMPTY>|<LONG HEADER> So the length of <EMPTY> is: LOC(SEG A+2) - ReadRecPtr - LEN(long header) - LEN(XLOG_SWITCH) If not, that is, it were not the last page of a segment. <-------------------- SEG A ---------------------------->|<-SEG A+1 < page n ->|<-- page n + 1 ---------->|....|<-last page->|<-first page <X_S_FIRST>|<SHORT HEADER><X_S_LAST><EMPTY..............>|<LONG HEADER> So the length of <EMPTY> in this case is: LOC(SEG A+1) - ReadRecPtr - LEN(short header) - LEN(XLOG_SWITCH) > >I'm not confindent on which is better, but I feel that this is not a > >work for display side, but for the recorder side like attached. > The patch really seems more clearly, but the new 'OTHERS' may confuse > the users and we hard to handle it with '--rmgr=RMGR' option. So I have > not use this design in this patch, let's see other's opinion. Yeah, I don't like the "OTHERS", too. > >Sorry for the confusion, but it would be a separate topic even if we > >are going to fix that.. > Sorry, I remove the code, make sense we should discuss it in a > separate topic. Agreed. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
pgsql-hackers by date: