On Thursday, 25 June 2020 21:41:54 CEST, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
> Adrian Klaver <adrian.klaver@aklaver.com> writes:
>> On 6/25/20 11:03 AM, Matthias Apitz wrote:
>>> I looked in the dump file after uncompressing it. The 'syntax error'
>>> comes from: one large table contains in a bytea column Perl code wich
>>> our software reads from the table and executes it with Perl. But, why
>>> the psql tryes to understand this code when it should INSERT it into the
>>> table?
>
> The perl fragment you show is similar to what's reported in the error
> message, but it doesn't quite match, so I'm not 100% sold on the
> theory that that's somehow not been quoted correctly. However,
> regardless of the exact details, it seems like the most likely theory
> about what is happening is that the dump file is corrupt and the
> corruption is causing the de-gzipped output to be missing or
> duplicating chunks of text. (Given the way gzip compression works,
> that wouldn't be a very surprising symptom.) So that leads me to
> wonder what was done to the dump file in between creation and use.
> One idea, seeing that the dump file was not given a ".gz" extension
> that would reflect its compressed state, is that something thought it
> was plain text and tried to do a newline conversion on it. If it was
> passed through email that would be a really plausible mechanism...
>
I have to check if the dump file was moved from one host to another, but
even if so, it was moved by scp.
I think, that a
gzip -dc foo
will work, regardless of the file names extensiom not beeing .gz
I think also, if the file have been corrupted on transport, gzip -dc ...
would complain about.
matthias
--
Sent from my Ubuntu phone
http://www.unixarea.de/
NO to the EU! NEIN zur EU!
