Re: pg_dump crashes

From: Nico De Ranter <nico(dot)deranter(at)esaturnus(dot)com>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_dump crashes
Date: 2020-05-25 05:30:21
Message-ID: CALVv0fajDBM7nB9joK-gcRbqyCGbfhA1P0VWPNw4iEHEmwcPcQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Unfortunately not. I discovered the issue rather late. The last working
backup is about 2 months old.

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

> On 5/22/20 8:17 AM, Nico De Ranter wrote:
> >
> >
> > On Fri, May 22, 2020 at 5:14 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
> > <mailto: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?
>
> Do you have recent previous backup?
>
> >
> > Nico
> >
> > --
> >
> > Nico De Ranter
> >
> > Operations Engineer
> >
>
>
>
> --
> Adrian Klaver
> adrian(dot)klaver(at)aklaver(dot)com
>

--

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andrus 2020-05-25 05:47:32 Re: Query returns no rows in pg_basebackup cluster
Previous Message Tom Lane 2020-05-25 01:52:26 Re: Query returns no rows in pg_basebackup cluster