Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump.
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump. |
| Дата | |
| Msg-id | 20201012011212.GC2346@paquier.xyz обсуждение |
| Ответ на | Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump. ("movead.li@highgo.ca" <movead.li@highgo.ca>) |
| Список | pgsql-hackers |
On Sat, Oct 10, 2020 at 09:50:02AM +0800, movead.li@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: XLOG len (rec/tot): 24/ 24, tx: 0, lsn: 0/030000D8, prev 0/03000060, desc: SWITCH,
trailing-bytes:16776936
static void
-XLogDumpRecordLen(XLogReaderState *record, uint32 *rec_len, uint32 *fpi_len)
+XLogDumpRecordLen(XLogReaderState *record, uint32 *rec_len, uint32 *fpi_len, uint32 *junk_len)
{
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 here. It seems to me that any extra information should be
added to xlog_desc() where there should be an extra code path for
(info == XLOG_SWITCH). XLogReaderState should have all the
information you are lookng for.
--
Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера