Re: pg_dump multi VALUES INSERT

Поиск
Список
Период
Сортировка
От Surafel Temesgen
Тема Re: pg_dump multi VALUES INSERT
Дата
Msg-id CALAY4q_4zAyum91dOZGvZmhpJR_s3hyO4wYAvERwh_K5kC4jsA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_dump multi VALUES INSERT  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: pg_dump multi VALUES INSERT  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers


On Mon, Feb 11, 2019 at 10:20 AM David Rowley <david.rowley@2ndquadrant.com> wrote:
Reviewing pg_dump-rows-per-insert-option-v14.
Also, maybe one for Fabien (because he seems keen on keeping the
--rows-per-insert validation code)

strtol() returns a long. dump_inserts is an int, so on machines where
sizeof(long) == 8 and sizeof(int) == 4 (most machines, these days) the
validation is not bulletproof.  This could lead to:

$ pg_dump --rows-per-insert=2147483648
pg_dump: rows-per-insert must be a positive number

fixed


For me, I was fine with the atoi() code that the other options use,
but maybe Fabien has a problem with the long vs int?


The main issue with atoi() is it does not detect errors and return 0 for
both invalid input and input value 0 but in our case it doesn't case a
problem because it error out for value 0. but for example in compress Level
if invalid input supplied it silently precede as input value 0 is supplied.
 
regards
Surafel
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Protect syscache from bloating with negative cache entries
Следующее
От: Andres Freund
Дата:
Сообщение: Re: reducing isolation tests runtime