| From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility |
| Date: | 2018-03-18 21:54:22 |
| Message-ID: | 5AAEE00E.9050503@anastigmatix.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-03-18 22:47:07 | Fixing some issues in matview.c's refresh-query construction |
| Previous Message | Thomas Munro | 2018-03-18 21:53:52 | Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3) |