Subject: Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
To: Daniel Gustafsson <daniel@yesql.se>, Tom Lane <tgl@sss.pgh.pa.us>
References: <579297F8.7020107@anastigmatix.net>
 <CA+TgmoaJR3s6CymT2wa9L5QR0pKY0cBthfece8MtxaBADMXw0Q@mail.gmail.com>
 <5797D953.6040806@anastigmatix.net> <20160802183347.GD32575@momjian.us>
 <CA+TgmobKFW5eVx4gd9TyiXv9iL_5DcC0-6UuJLXvwG1Ft1Pn-g@mail.gmail.com>
 <20943eba-bbb9-390c-01b1-e6704ce33c7b@iki.fi>
 <594C9457.6000708@anastigmatix.net> <59506148.1010708@anastigmatix.net>
 <2b9ed9a4-56a6-a4db-0abf-3527d993e2d4@iki.fi>
 <fe79f7c5-2bc5-f763-8908-78675ba33eba@anastigmatix.net>
 <d190140f-b6e8-5e2f-c663-c8f9617da18e@iki.fi>
 <CAB7nPqQr1D3gjx8CmHYQREidG2eeGHzx2yQ97B3t2L99GE=+kQ@mail.gmail.com>
 <5A92F0C0.7070706@anastigmatix.net>
 <C0523BD1-485D-48B5-982E-8D63E2D001B7@yesql.se>
 <5AADB130.2020206@anastigmatix.net> <4597.1521338981@sss.pgh.pa.us>
 <46FFB930-B0F3-400A-85ED-D9948C97FADF@yesql.se>
Cc: Michael Paquier <michael.paquier@gmail.com>,
 Heikki Linnakangas <hlinnaka@iki.fi>, Robert Haas <robertmhaas@gmail.com>,
 Bruce Momjian <bruce@momjian.us>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
From: Chapman Flack <chap@anastigmatix.net>
Message-ID: <5AAEE00E.9050503@anastigmatix.net>
Date: Sun, 18 Mar 2018 17:54:22 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <46FFB930-B0F3-400A-85ED-D9948C97FADF@yesql.se>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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