Re: pg_basebackup failed to back up large file

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_basebackup failed to back up large file
Date: 2014-06-09 09:17:41
Message-ID: CABUevExJHg=V4GMSfaFx2uZ0AJ4Gs5Vo8pxMJDEJYO=-geedOQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday, June 4, 2014, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Magnus Hagander <magnus(at)hagander(dot)net <javascript:;>> writes:
> > On Tue, Jun 3, 2014 at 6:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> <javascript:;>> wrote:
> >> Another thought is we could make pg_basebackup simply skip any files
> that
> >> exceed RELSEG_SIZE, on the principle that you don't really need/want
> >> enormous log files to get copied anyhow. We'd still need the pax
> >> extension if the user had configured large RELSEG_SIZE, but having a
> >> compatible tar could be documented as a requirement of doing that.
>
> > I think going all the way to pax is the proper long-term thing to do, at
> > least if we can confirm it works in the main tar implementations.
>
> > For backpatchable that seems more reasonable. It doesn't work today, and
> we
> > just need to document that it doesn't, with larger RELSEG_SIZE. And then
> > fix it properly for the future.
>
> Agreed, this would be a reasonable quick fix that we could replace in
> 9.5 or later.
>
>
Fujii, are you going to be able to work on this with the now expanded
scope? :)

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2014-06-09 10:01:54 Re: Allowing NOT IN to use ANTI joins
Previous Message b8flowerfire 2014-06-09 08:06:24 why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller