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-03 14:53:59
Message-ID: CABUevExLPG6BxG999YLjKt72r87V7RobQmJSJH2_TwbdyyXBoQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 3, 2014 at 4:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2014-06-03 23:19:37 +0900, Fujii Masao wrote:
> >> - if (sscanf(copybuf + 124, "%11o",
> &current_len_left) != 1)
> >> + if (sscanf(copybuf + 124, "%11lo",
> &current_len_left) != 1)
>
> > That's probably not going to work on 32bit platforms or windows where
> > you might need to use ll instead of l as a prefix. Also notice that
> > apparently (c.f. 9d7ded0f4277f5c0063eca8e871a34e2355a8371) sscanf can't
> > reliably be used for 64bit input :(. That pretty much sucks...
>
> 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 there, that's when we read it. But
print_val() on the server side should probably have an overflow check
there, which it doesn't. It's going to write some strange values int here
if it overflows..

--
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 Tom Lane 2014-06-03 14:55:17 Re: strtoll/strtoull emulation
Previous Message Greg Stark 2014-06-03 14:53:16 Re: Proposal for CSN based snapshots