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
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 |