Re: pg_dump seems to be broken in regards to the "--exclude-table-data" option on Windows.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>
Cc: tutiluren(at)tutanota(dot)com, Pgsql Bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_dump seems to be broken in regards to the "--exclude-table-data" option on Windows.
Date: 2020-07-29 14:10:21
Message-ID: 1314531.1596031821@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de> writes:
> Didn't you mention that once you could overcome the runtime errors you
> still have seen some unexpected output from pg_dump? A script that one can
> download and run on their (Windows) system would help to confirm the
> problem (if it does reproduce on others' systems) and speed up diagnosys
> and a fix, if required.

My understanding of what's happening here (admittedly, I've not been
paying really close attention) is that some component is misprocessing
non-ASCII data as it's being typed into the pg_dump shell command.
That being the case, I'm not sure that a pre-written shell script could
reproduce the issue accurately. A script to create the initial database
contents would surely be helpful, but the steps after that might need to
be more like "type this into the terminal, and then you will get X instead
of Y".

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Fujii Masao 2020-07-29 14:24:33 Re: pg_stat_statements: rows not updated for CREATE TABLE AS SELECT statements
Previous Message Marco Carlo Moriggi 2020-07-29 10:37:39 Planner using wrong composite index with date interval statically calculated