On Sat, Sep 3, 2016 at 3:21 PM, Michael Paquier <michael.paqu...@gmail.com> wrote:
> On Sat, Sep 3, 2016 at 12:42 AM, Magnus Hagander <mag...@hagander.net> > wrote: > > On Fri, Sep 2, 2016 at 8:50 AM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > >> On Fri, Sep 2, 2016 at 2:20 AM, Peter Eisentraut > >> <peter.eisentr...@2ndquadrant.com> wrote: > >> > On 5/13/16 2:39 AM, Michael Paquier wrote: > >> What do others think about that? I could implement that on top of 0002 > >> with some extra options. But to be honest that looks to be just some > >> extra sugar for what is basically a bug fix... And I am feeling that > >> providing such a switch to users would be a way for one to shoot > >> himself badly, particularly for pg_receivexlog where a crash can cause > >> segments to go missing. > >> > > > > Well, why do we provide a --nosync option for initdb? Wouldn't the > argument > > basically be the same? > > Yes, the good-for-testing-but-not-production argument. > > > I agree it kind of feels like overkill, but it would be consistent > overkill? > > :) > > Oh, well. I have just implemented it on top of the two other patches > for pg_basebackup. For pg_receivexlog, I am wondering if it makes > sense to have it. That would be trivial to implement it, and I think > that we had better make the combination of --synchronous and --nosync > just leave with an error. Thoughts about having that for > pg_receivexlog? > Yes, we should definitely not allow that combination. In fact, maybe that argument in itself is enough not to have it for pg_receivexlog -- the cause of confusion. I can see how you might want to avoid it for pg_basebackup during testing for example,. but the overhead on pg_receivexlog shouldn't be as bad in testing, should it? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
