Magnus Hagander <magnus@hagander.net> writes:
> Yeah, there's clearly a second problem here.
I think this test script is broken in many ways.
It's scribbling on the source cluster's disk files and assuming that that
translates one-for-one to what gets sent to the slave server --- but what
if some of the blocks that it modifies on-disk are resident in the
source's shared buffers? I think you'd have to shut down the source and
then apply the corruption if you want stable results.
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.
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.
regards, tom lane
