Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

> On 18 Mar 2018, at 22:54, Chapman Flack <chap(at)anastigmatix(dot)net> wrote:
>
> 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. :)

Good point, thats what I get for hacking without enough coffee.

> What would you think about replacing the last two lines with just
>
> ok($bytes =~ /\A\x00*+\z/, 'make sure wal segment is zeroed’);

It seems expensive to regex over BLCKSZ, but it’s probably the safest option
and it’s not a performance critical codepath. Feel free to whack the test
patch over the head with the above diff.

cheers ./daniel