pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Chapman Flack <chap@anastigmatix.net>
To: Daniel Gustafsson <daniel@yesql.se>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
Date: Sun, 18 Mar 2018 17:54:22 -0400
Message-ID: <5AAEE00E.9050503@anastigmatix.net> (raw)
In-Reply-To: <46FFB930-B0F3-400A-85ED-D9948C97FADF@yesql.se>
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>

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




view thread (49+ messages)  latest in thread

Message-ID: <5AAEE00E.9050503@anastigmatix.net>
Permalink:  ../5AAEE00E.9050503@anastigmatix.net/
Also on:    postgresql.org/message-id/5AAEE00E.9050503@anastigmatix.net

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: chap@anastigmatix.net, daniel@yesql.se, tgl@sss.pgh.pa.us, michael.paquier@gmail.com, hlinnaka@iki.fi, robertmhaas@gmail.com, bruce@momjian.us
  Subject: Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
  In-Reply-To: <5AAEE00E.9050503@anastigmatix.net>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox