Re: Parallel pg_dump's error reporting doesn't work worth squat

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Parallel pg_dump's error reporting doesn't work worth squat
Date: 2016-05-25 14:11:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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(at)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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-05-25 14:14:39 Re: Does people favor to have matrix data type?
Previous Message Tom Lane 2016-05-25 14:02:13 Re: [BUGS] BUG #14155: bloom index error with unlogged table