Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

Поиск
Список
Период
Сортировка
От Chapman Flack
Тема Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
Дата
Msg-id 5AAEE00E.9050503@anastigmatix.net
обсуждение исходный текст
Ответ на Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility  (Daniel Gustafsson <daniel@yesql.se>)
Ответы Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
On 03/18/18 16:56, Daniel Gustafsson wrote:
> sorry about that.  Now we know that the proposed test fails without the patch
> applied and clears with it, that was at least an interesting side effect =)

It was, and it got me looking at the test, and even though it does detect
the difference between patch-applied and patch-not-applied, I sort of wonder
if it does what it claims to. It seems to me that unpack('N8192', ...)
would want to return 8192 32-bit ints (in array context), but really only
be able to return 2048 of them (because it's only got 8192 bytes to unpack),
and then being used in scalar context, it only returns the first one anyway,
so the test only hinges on whether the first four bytes of the block are
zero or not. Which turns out to be enough to catch a non-zeroed header. :)

What would you think about replacing the last two lines with just

  ok($bytes =~ /\A\x00*+\z/, 'make sure wal segment is zeroed');

-Chap


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3)
Следующее
От: Tom Lane
Дата:
Сообщение: Fixing some issues in matview.c's refresh-query construction