On Thu, Sep 1, 2016 at 9:43 AM, Michael Paquier <michael.paqu...@gmail.com>

> On Thu, Sep 1, 2016 at 4:41 PM, Magnus Hagander <mag...@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? :)

 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Reply via email to