<p dir="ltr"><p dir="ltr">On 3 Sep. 2016 9:22 pm, "Michael Paquier" <<a
href="mailto:michael.paquier@gmail.com">michael.paquier@gmail.com</a>>wrote:<br /> ><br /> > On Sat, Sep 3,
2016at 12:42 AM, Magnus Hagander <<a href="mailto:magnus@hagander.net">magnus@hagander.net</a>> wrote:<br /> >
>On Fri, Sep 2, 2016 at 8:50 AM, Michael Paquier <<a
href="mailto:michael.paquier@gmail.com">michael.paquier@gmail.com</a>><br/> > > wrote:<br /> > >> On
Fri,Sep 2, 2016 at 2:20 AM, Peter Eisentraut<br /> > >> <<a
href="mailto:peter.eisentraut@2ndquadrant.com">peter.eisentraut@2ndquadrant.com</a>>wrote:<br /> > >> >
On5/13/16 2:39 AM, Michael Paquier wrote:<br /> > >> What do others think about that? I could implement that
ontop of 0002<br /> > >> with some extra options. But to be honest that looks to be just some<br /> >
>>extra sugar for what is basically a bug fix... And I am feeling that<br /> > >> providing such a
switchto users would be a way for one to shoot<br /> > >> himself badly, particularly for pg_receivexlog where
acrash can cause<br /> > >> segments to go missing.<br /> > >><br /> > ><br /> > > Well,
whydo we provide a --nosync option for initdb? Wouldn't the argument<br /> > > basically be the same?<br />
><br/> > Yes, the good-for-testing-but-not-production argument.<p dir="ltr">We need it for tap tests. More and
morewill use pg_basebackup and it'll start hurting test speeds badly.<br />