Re: pg_dumpall and restore
От | Laurenz Albe |
---|---|
Тема | Re: pg_dumpall and restore |
Дата | |
Msg-id | 47175ca8aea768568fb51e1a91c94d436ef79d97.camel@cybertec.at обсуждение исходный текст |
Ответ на | pg_dumpall and restore ("Rossi, Maria" <maria.rossi@jackson.com>) |
Ответы |
Re: pg_dumpall and restore
Re: pg_dumpall and restore RE: pg_dumpall and restore RE: pg_dumpall and restore |
Список | pgsql-sql |
Rossi, Maria wrote: > I upgraded our postgres database from V9.3 to V10.5. Used pg_dumpall then restore it to the new instance. > After the restore, we notice that 1 table had duplicate rows, such that it was not able to create the primary key. > I checked the old database, it does not have the dups. > Has anyone encountered having dups rows loaded? Any idea what caused this and how to prevent? > > Your help would be much appreciated. I don't believe that pg_dumpall miraculously duplicated the row. You probably *do* have a duplicate row, and hence table corruption, but I suspect that one of the rows is not in the index you used to look for the row. If you query: SELECT * FROM tab WHERE id = 42; the query will likely use the index on "id" and find only one of the rows. You should SET enable_indexscan = off; SET enable_indexonlyscan = off; and then repeat the query, so that a sequential scan is used. To fix, delete one of the rows and reindex. You can identify a row by its tuple id: SELECT ctid, * FROM tab WHERE id = 42; Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com
В списке pgsql-sql по дате отправления: