On Thu, Sep 1, 2016 at 4:41 PM, Magnus Hagander <magnus@hagander.net> wrote: > That's definitely not intended - it's supposed to be 16Mb. And it actually > writes 16Mb to the tarfile, it's the extraction that doesn't see them. That > also means that if you get more than one member of the tarfile at this > point, it will be corrupt. (It's not corrupt in the .tar.gz case, clearly my > testing of the very last iteration of the patch forgot to doublecheck this > with both). > > Oops. Will fix.
If at the same time you could add some tests in pg_basebackup/t, that would be great :)
That's definitely on my slightly-longer-term plan. But I've successfully managed to avoid perl long enough now that looking at the code in those tests is mighty confusing :) So I need a bunch of readup before I can figure that out. (yes, that means I've managed to avoid our own discussions about that style tests on this list quite successfully too :P)
We don't seem to check for similar issues as the one just found in the existing tests though, do we? As in, we don't actually verify that the xlog files being streamed are 16Mb? (Or for that matter that the tarfile emitted by -Ft is actually a tarfile?) Or am I missing some magic somewhere? :)
