Re: pg_dump crashes

On Fri, May 22, 2020 at 5:14 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

> On 5/22/20 8:05 AM, Nico De Ranter wrote:
> >
>
> >
> > 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.
> >
> >
> > But that would be content of the database only. The should matter for
> > the application but not for a dump of the database, right?
>
> Also what does:
>
> \d public.file
>
> show?
>
> In particular are there any triggers on the table?
>

bacula=# \d public.file
Table "public.file"
Column | Type | Collation | Nullable | Default

------------+----------+-----------+----------+--------------------------------------
fileid | bigint | | not null |
nextval('file_fileid_seq'::regclass)
fileindex | integer | | not null | 0
jobid | integer | | not null |
pathid | integer | | not null |
filenameid | integer | | not null |
deltaseq | smallint | | not null | 0
markid | integer | | not null | 0
lstat | text | | not null |
md5 | text | | not null |
Indexes:
"file_pkey" PRIMARY KEY, btree (fileid)
"file_jobid_idx" btree (jobid)
"file_jpfid_idx" btree (jobid, pathid, filenameid)

Following up on the max(bigint), I tried

SELECT md5 FROM public.file where fileid >2087994666;

and got

ERROR: compressed data is corrupted

So it does look like those entries are killing it. Now for the
million-dollar question: how do I get them out?

Nico

--

Nico De Ranter

Operations Engineer

T. +32 16 38 72 10

<http://www.esaturnus.com>

<http://www.esaturnus.com>

eSATURNUS
Philipssite 5, D, box 28
3001 Leuven – Belgium

T. +32 16 40 12 82
F. +32 16 40 84 77
www.esaturnus.com

<http://www.esaturnus.com/>

*For Service & Support :*

Support Line Belgium: +32 2 2009897

Support Line International: +44 12 56 68 38 78

Or via email : medical(dot)services(dot)eu(at)sony(dot)com