Re: Parallel pg_dump's error reporting doesn't work worth squat
От | Tom Lane |
---|---|
Тема | Re: Parallel pg_dump's error reporting doesn't work worth squat |
Дата | |
Msg-id | 24577.1464185488@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Parallel pg_dump's error reporting doesn't work worth squat (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: Parallel pg_dump's error reporting doesn't work
worth squat
|
Список | pgsql-hackers |
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes: > I tried it on Windows 7/64 but first of all, I'm surprised to see > that the following command line gets an error but it would be > fine because it is consistent with what is written in the manual. > | >pg_dump postgres://horiguti:hoge@localhost/postgres --jobs=9 -Fd -f testdump > | pg_dump: too many command-line arguments (first is "--jobs=9") > | Try "pg_dump --help" for more information. Where do you see an example like that? We should fix it. The only case that is certain to work is switches before non-switch arguments, and so we should not give any documentation examples in the other order. On a platform using GNU getopt(), getopt() will rearrange the argv[] array to make such cases work, but non-GNU getopt() doesn't do that (and I don't really trust the GNU version not to get confused, either). > I might be wrong with something, but pg_dump seems to have some > issues in thread handling. Wouldn't surprise me ... there's a lot of code in there depending on static variables, and we've only tried to thread-proof a few. Still, I think that's a separate issue from what this patch is addressing. regards, tom lane
В списке pgsql-hackers по дате отправления: