From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
cc: Chapman Flack <chap@anastigmatix.net>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Michael Paquier <michael@paquier.xyz>,
        Daniel Gustafsson <daniel@yesql.se>,
        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>
Subject: Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility
In-reply-to: <20180330182423.GS24540@tamriel.snowman.net>
References: <46FFB930-B0F3-400A-85ED-D9948C97FADF@yesql.se>
 <5AAEE00E.9050503@anastigmatix.net>
 <21C25ED8-4ED8-4AD4-B551-3E3987ECB18F@yesql.se>
 <5AAEFF11.3070903@anastigmatix.net>
 <20180326032731.GM24540@tamriel.snowman.net>
 <20180326054354.GB2759@paquier.xyz> <5ABAC668.5080203@anastigmatix.net>
 <8c00b26a-d6da-5764-e67e-9c4d8128081a@2ndquadrant.com>
 <5ABD9083.5050908@anastigmatix.net> <12915.1522433926@sss.pgh.pa.us>
 <20180330182423.GS24540@tamriel.snowman.net>
Comments: In-reply-to Stephen Frost <sfrost@snowman.net>
	message dated "Fri, 30 Mar 2018 14:24:23 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <24352.1522441284.1@sss.pgh.pa.us>
Date: Fri, 30 Mar 2018 16:21:24 -0400
Message-ID: <24353.1522441284@sss.pgh.pa.us>
Precedence: bulk

Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> A potentially stronger complaint is that WAL-reading tools might fail
>> outright on a page with an invalid header, but I'd say that's a robustness
>> issue that they'd need to address anyway.  There's never been any
>> guarantee that the trailing pages of a WAL segment are valid.

> Agreed, I don't buy off that tools which fall apart when reading a page
> with an invalid header should block this from moving forward- those
> tools need to be fixed to not rely on trailing/unused WAL pages to be
> valid.

Yup.  Pushed with some rewriting of the comments.

I did not like the proposed test case too much, particularly not its
undocumented API change for check_pg_config, so I did not push that.
We already have test coverage for pg_switch_wal() so it doesn't seem
very critical to have more.

			regards, tom lane