Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility - Mailing list pgsql-hackers

From Chapman Flack
Subject Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
Date
Msg-id 5AAEE00E.9050503@anastigmatix.net
Whole thread Raw
In response to Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility  (Daniel Gustafsson <daniel@yesql.se>)
List 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 by date:

Previous
From: Thomas Munro
Date:
Subject: Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3)
Next
From: Tom Lane
Date:
Subject: Fixing some issues in matview.c's refresh-query construction