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.
Applied, with the addition that I explicitly disabled autovacuum on those tables as well.
We might want to enhance it further by calculating the figure 10,000 based on blocksize perhaps?