Re: BUG #16732: pg_dump creates broken backups
| От | David G. Johnston |
|---|---|
| Тема | Re: BUG #16732: pg_dump creates broken backups |
| Дата | |
| Msg-id | CAKFQuwZK43BHjM-yBLDGrxdLtM5aqkS9fkSTJ=oOnxMFv8=VxA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #16732: pg_dump creates broken backups (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: BUG #16732: pg_dump creates broken backups
|
| Список | pgsql-bugs |
On Fri, Nov 20, 2020 at 6:03 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Zsolt Ero <zsolt.ero@gmail.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?
В списке pgsql-bugs по дате отправления: