Re: pg_basebackup failed to back up large file
| От | Magnus Hagander |
|---|---|
| Тема | Re: pg_basebackup failed to back up large file |
| Дата | |
| Msg-id | CABUevExLPG6BxG999YLjKt72r87V7RobQmJSJH2_TwbdyyXBoQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pg_basebackup failed to back up large file (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: pg_basebackup failed to back up large file
|
| Список | pgsql-hackers |
On Tue, Jun 3, 2014 at 4:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> - if (sscanf(copybuf + 124, "%11o", ¤t_len_left) != 1)There's a far bigger problem there, which is if we're afraid that
>> + if (sscanf(copybuf + 124, "%11lo", ¤t_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...
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/
В списке pgsql-hackers по дате отправления: