Re: pg_dump crashes

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Nico De Ranter <nico(dot)deranter(at)esaturnus(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_dump crashes
Date: 2020-05-22 15:01:56
Message-ID: c1d837db-0bd8-5e41-d276-b74ab9d98920@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 5/22/20 7:55 AM, Nico De Ranter wrote:
> Correct.
>
> If I run 'pg_dumpall --cluster 11/main --file=dump.sql'   the end of the
> file looks like:
>
> ###### cut here
> 4557430888798830399 1061109567 1061109567 1061109567 1061109567 16191 \N
> \N ??????????????????????????????
> 4557430888798830399 1061109567 1061109567 1061109567 1061109567 16191 \N
> \N ??????????????????????????????
> \.
>
> ###### cut here
>
> If I run 'pg_dump --table=public.file --cluster 11/main
> --file=dump-2.sql bacula'  those lines are actually followed by about
> 850 or so lines that look ok.  I'm assuming the difference is due to
> buffering.
> However the fact that I do see a number of regular lines following this
> may suggest it's just garbage in the table but not really causing the
> issue afterall.

Assuming the above matches:

COPY public.file (fileid, fileindex, jobid, pathid, filenameid,
deltaseq, markid, lstat, md5)

the '????????????????????' would be for the md5 field. I'm going to say
that is important.

>
> Nico
>
>
>

>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Nico De Ranter 2020-05-22 15:05:08 Re: pg_dump crashes
Previous Message Nico De Ranter 2020-05-22 14:55:20 Re: pg_dump crashes