Re: pg_basebackup failed to back up large file - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: pg_basebackup failed to back up large file
Date
Msg-id CABUevExJHg=V4GMSfaFx2uZ0AJ4Gs5Vo8pxMJDEJYO=-geedOQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_basebackup failed to back up large file  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_basebackup failed to back up large file  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Wednesday, June 4, 2014, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Jun 3, 2014 at 6:38 PM, Tom Lane <tgl@sss.pgh.pa.us> 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/

pgsql-hackers by date:

Previous
From: b8flowerfire
Date:
Subject: why postgresql define NTUP_PER_BUCKET as 10, not other numbers smaller
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Allowing NOT IN to use ANTI joins