Re: pg_dump multi VALUES INSERT
Surafel Temsgen <surafel3000@gmail.com>
From: Surafel Temesgen <surafel3000@gmail.com>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>,
Dmitry Dolgov <9erthalion6@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-02-13T06:36:46Z
Lists: pgsql-hackers
Attachments
- pg_dump-rows-per-insert-option-v15.patch (text/x-patch) patch v15
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
Commits
-
Add pg_dumpall --rows-per-insert
- a193cbec1199 12.0 landed
-
pg_dump: allow multiple rows per insert
- 7e413a0f82c8 12.0 landed