On Mon, Jun 9, 2014 at 11:17:41AM +0200, Magnus Hagander wrote:
> On Wednesday, June 4, 2014, Tom Lane wrote:
>
> Magnus Hagander writes:
> > On Tue, Jun 3, 2014 at 6:38 PM, Tom Lane wrote:
> >> Another thought is we could make pg_basebackup simply skip any files
> that
> >
On Wednesday, June 4, 2014, Tom Lane wrote:
> Magnus Hagander > writes:
> > On Tue, Jun 3, 2014 at 6:38 PM, Tom Lane > 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 l
Magnus Hagander writes:
> On Tue, Jun 3, 2014 at 6:38 PM, Tom Lane 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
>> ex
On Tue, Jun 3, 2014 at 6:38 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > Yeah, that is a clear advantage of that method. Didn't read up on pax
> > format backwards compatibility, does it have some trick to achieve
> > something similar?
>
> I didn't read the fine print but it sounded like t
Magnus Hagander writes:
> Yeah, that is a clear advantage of that method. Didn't read up on pax
> format backwards compatibility, does it have some trick to achieve
> something similar?
I didn't read the fine print but it sounded like the extended header
would look like a separate file entry to a
On 2014-06-03 18:23:07 +0200, Magnus Hagander wrote:
> On Jun 3, 2014 6:17 PM, "Andres Freund" wrote:
> > PG's tar.c already uses the ustar format and the referenced extension is
> > an extension to ustar as far as I understand it. So at least tarballs
> > with files < 8GB would still continue to
On Jun 3, 2014 6:17 PM, "Andres Freund" wrote:
>
> On 2014-06-03 17:57:52 +0200, Magnus Hagander wrote:
> > On Tue, Jun 3, 2014 at 5:42 PM, Tom Lane wrote:
> > > What we had better do, IMO, is fix things so that we don't have a
filesize
> > > limit in the basebackup format. After a bit of googli
On 2014-06-03 17:57:52 +0200, Magnus Hagander wrote:
> On Tue, Jun 3, 2014 at 5:42 PM, Tom Lane wrote:
> > What we had better do, IMO, is fix things so that we don't have a filesize
> > limit in the basebackup format. After a bit of googling, I found out that
> > recent POSIX specs for tar format
On 2014-06-03 11:42:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-03 11:04:58 -0400, Tom Lane wrote:
> >> My point is that having backups crash on an overflow doesn't really seem
> >> acceptable. IMO we need to reconsider the basebackup protocol and make
> >> sure we don't *nee
On Tue, Jun 3, 2014 at 5:42 PM, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-03 11:04:58 -0400, Tom Lane wrote:
> >> My point is that having backups crash on an overflow doesn't really seem
> >> acceptable. IMO we need to reconsider the basebackup protocol and make
> >> sure we don't
Andres Freund writes:
> On 2014-06-03 11:04:58 -0400, Tom Lane wrote:
>> My point is that having backups crash on an overflow doesn't really seem
>> acceptable. IMO we need to reconsider the basebackup protocol and make
>> sure we don't *need* to put values over 4GB into this field. Where's the
On Tue, Jun 3, 2014 at 5:12 PM, Andres Freund
wrote:
> On 2014-06-03 11:04:58 -0400, Tom Lane wrote:
> > Magnus Hagander writes:
> > > On Tue, Jun 3, 2014 at 4:40 PM, Tom Lane wrote:
> > >> There's a far bigger problem there, which is if we're afraid that
> > >> current_len_left might exceed 4G
On 2014-06-03 11:04:58 -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Tue, Jun 3, 2014 at 4:40 PM, Tom Lane wrote:
> >> There's a far bigger problem there, which is if we're afraid that
> >> current_len_left might exceed 4GB then what is it exactly that guarantees
> >> it'll fit in an 11
Magnus Hagander writes:
> On Tue, Jun 3, 2014 at 4:40 PM, Tom Lane wrote:
>> There's a far bigger problem there, which is if we're afraid that
>> current_len_left might exceed 4GB then what is it exactly that guarantees
>> it'll fit in an 11-digit field?
> Well, we will only write 11 digits in t
On Tue, Jun 3, 2014 at 4:40 PM, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-03 23:19:37 +0900, Fujii Masao wrote:
> >> -if (sscanf(copybuf + 124, "%11o",
> ¤t_len_left) != 1)
> >> +if (sscanf(copybuf + 124, "%11lo",
> ¤t_len_left) != 1)
>
> > Th
Andres Freund writes:
> On 2014-06-03 23:19:37 +0900, Fujii Masao wrote:
>> -if (sscanf(copybuf + 124, "%11o", ¤t_len_left) !=
>> 1)
>> +if (sscanf(copybuf + 124, "%11lo", ¤t_len_left)
>> != 1)
> That's probably not going to work on 32bit platforms or win
Hi
On 2014-06-03 23:19:37 +0900, Fujii Masao wrote:
> I got the bug report of pg_basebackup off-list that it causes an error
> when there is large file (e.g., 4GB) in the database cluster. It's easy
> to reproduce this problem.
>
> The cause of this problem is that pg_basebackup uses an integer t
17 matches
Mail list logo
