Re: BUG #16732: pg_dump creates broken backups

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Zsolt Ero <zsolt(dot)ero(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16732: pg_dump creates broken backups
Date: 2020-11-21 01:20:15
Message-ID: CAKFQuwZK43BHjM-yBLDGrxdLtM5aqkS9fkSTJ=oOnxMFv8=VxA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Nov 20, 2020 at 6:03 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Zsolt Ero <zsolt(dot)ero(at)gmail(dot)com> writes:
> > It happens with 1 row in a 3 GB gzip compressed database dump. I'm
> > thinking about how could I possibly give you a reproducible case. Do you
> > know any way which doesn't require me to share the whole production
> > database? (which is not an option)
>
> Of course not. Can you make it happen with a few rows of dummy data
> within the same schema?
>
>
Before doing that, have you positively confirmed that map_id=112664 exists
on the maps table in the live database? Your follow-on post is difficult
to follow. The claim about "1 record" in a database would suggest
corruption, not a structural problem - which should affect entire tables
(though you'd only see the first error). In the dump file, is 112664 the
first ID in the table data?

David J.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-11-21 02:45:08 Re: BUG #16732: pg_dump creates broken backups
Previous Message Tom Lane 2020-11-21 01:03:36 Re: BUG #16732: pg_dump creates broken backups