Hi,
On Tue, Apr 03, 2018 at 08:48:08PM +0200, Magnus Hagander wrote:
> On Tue, Apr 3, 2018 at 8:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'd bet a good lunch that nondefault BLCKSZ would break it, as well,
> > since the way in which the corruption is induced is just guessing
> > as to where page boundaries are.
>
> Yeah, that might be a problem. Those should be calculated from the block
> size.
>
> Also, scribbling on tables as sensitive as pg_class is just asking for
> > trouble IMO. I don't see anything in this test, for example, that
> > prevents autovacuum from running and causing a PANIC before the test
> > can complete. Even with AV off, there's a good chance that clobber-
> > cache-always animals will fall over because they do so many more
> > physical accesses to the system catalogs. I'd suggest inducing the
> > corruption in some user table(s) that we can more tightly constrain
> > the source server's accesses to.
>
> Yeah, that seems like a good idea. And probably also shut the server down
> while writing the corruption, just in case.
>
> Will stick looking into that on my todo for when I'm back, unless beaten to
> it. Michael, you want a stab at it?
Attached is a patch which does that hopefully:
1. creates two user tables, one large enough for at least 6 blocks
(around 360kb), the other just one block.
2. stops the cluster before scribbling over its data and starts it
afterwards.
3. uses the blocksize (and the pager header size) to determine offsets
for scribbling.
I've tested it with blocksizes 8 and 32 now, the latter should make sure
that the first table is indeed large enough, but maybe something less
arbitrary than "10000 integers" should be used?
Anyway, sorry for the hassle.
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.banck@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer