Tom Lane wrote:
> Hm. In theory, that truncation failure in itself shouldn't have caused a
> problem --- autovacuum is just trying to remove some empty pages, and if
> they don't get removed, they'd still be empty. However, there's a problem
> if the pages are empty because we just deleted some
Olga Vingurt writes:
> The only question left is how we got into corrupted data state.
> In the event logs (PorstgeSQL is runnign on Wondows Server) we found error
> which looks relevant:
> ERROR: could not truncate file "base/12373/17254" to 19 blocks: Permission
> denied
> CONTEXT: automatic
The data indeed wasn't consistent on the source system and foreign key
index was corrupted.
After manually cleaning not relevant records and running REINDEX on the
table pd_dump and pg_restore worked as expected.
The only question left is how we got into corrupted data state.
In the event logs (Po
Hi,
El lun., 10 dic. 2018 a las 7:21, Andreas Kretschmer (<
andr...@a-kretschmer.de>) escribió:
>
> Am 10.12.18 um 11:15 schrieb Olga Vingurt:
> > After playing with the dump and importing schema first and data next
> > without the triggers we indeed see that data is missing in the table
> > i.e.
Am 10.12.18 um 11:15 schrieb Olga Vingurt:
After playing with the dump and importing schema first and data next
without the triggers we indeed see that data is missing in the table
i.e. dump is not consistent.
We don't stop the application which uses database during the dump but
according to
Hi,
We are using PostgresSQL 9.5.10 and pg_dump/pg_restore to export and import
database.
We encountered an issue (which is not easily reproducible) when running
pg_restore:
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3624; 2606 37504 F
