'PostgreSQL backup in custom format ( -F c) fails during pg_restore ( copy command in log )
We have a PostgreSQL custom format ( -F c ) database backup ~1Gb in size that could not be restored on two of our users machines. The error that occurs is
:pg_restore: [archiver (db)] error returned by PQputCopyData and in logs there is error in Copy command.
All reports we found with errors in Copy command during pg_restore were related to textual (sql ) backup which is not the case.
Any ideas?
Below is the information that describe the issue in more details:
1. File integrity is ok checked with "Microsoft File Checksum Integrity Verifier"
2. Backup and restore and restore are performed with PostgreSQL 9.6.5 64 bit.
3. Backup format of pg_dump is called
pg_dump -U username -F c -Z 9 mydatabase > myarchive
4. Database on client is created with:
CREATE DATABASE mydatabase WITH TEMPLATE = template0 ENCODING = 'UTF8' OWNER=user;
5. Pg_resote call:
pg_restore.exe -U user --dbname=mydatabase --verbose --no-owner --role=user
6. Example of logs, there are repeating rows with random table errors:
2020-12-07 13:40:56 GMT LOG: checkpoints are occurring too frequently (21 seconds apart)
2020-12-07 13:40:56 GMT HINT: Consider increasing the configuration parameter "max_wal_size".
2020-12-07 13:40:57 GMT ERROR: extra data after last expected column
2020-12-07 13:40:57 GMT CONTEXT: COPY substance, line 21511: "21743 \N 2 1d8c29d2d4dc17ccec4a29710c2f190a e98906e08d4cf1ac23bc4a5a26f83e73 1d8c29d2d4dc17ccec4a297..."
2020-12-07 13:40:57 GMT STATEMENT: COPY substance (id, text_id, storehouse_id, i_tb_id, i_twod_tb_id, tb_id, twod_tb_id, o_smiles, i_smiles_id, i_twod_smiles_id, smiles_id, twod_smiles_id, substance_type)
2020-12-07 13:40:57 GMT FATAL: invalid frontend message type 48
2020-12-07 13:40:57 GMT LOG: PID 105976 in cancel request did not match any process
or
2020-12-07 14:35:42 GMT LOG: checkpoints are occurring too frequently (16 seconds apart)
2020-12-07 14:35:42 GMT HINT: Consider increasing the configuration parameter "max_wal_size".
2020-12-07 14:35:59 GMT LOG: checkpoints are occurring too frequently (17 seconds apart)
2020-12-07 14:35:59 GMT HINT: Consider increasing the configuration parameter "max_wal_size".
2020-12-07 14:36:09 GMT ERROR: invalid byte sequence for encoding "UTF8": 0x00
2020-12-07 14:36:09 GMT CONTEXT: COPY scalar_calculation, line 3859209
2020-12-07 14:36:09 GMT STATEMENT: COPY scalar_calculation (calculator_id, smiles_id, mean_value, remark) FROM stdin;
2020-12-07 14:36:09 GMT FATAL: invalid frontend message type 49
2020-12-07 14:36:10 GMT LOG: PID 109816 in cancel request did not match any process
Solution 1:[1]
I am seeing similar behavior on windows 10 pro machines with PG 11.x.
I used pg_dump as suggested above and restored to said machines with psql and had no error.
I also noted that the error shifted around using pg_restore with different "-j" settings. For instance without the setting or "-j 1" pg_restore always fails on the same table and record. Changing to "-j 4" results in that table succeeding to apply the record without error but it occurs on another table.
Changing a particular column to null in the record satisfies the entire restore.
Using pgAdmin 4 to run the restore never produces the error. Copying the exact command displayed in pgAdmin reproduces the same error:
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 32780; 0 5435293 TABLE DATA REDACTED_TABLE_NAME postgres
pg_restore: [archiver (db)] COPY failed for table "REDACTED_TABLE_NAME": ERROR: extra data after last expected column
CONTEXT: COPY mi_gmrfutil, line 117: "REDACTED PLAIN TEXT \N REDACTED PLAIN TEXT \N \N \N \N \N \N REDACTED PLAIN TEXT \N \N REDACTED PLAIN TEXT \N ..."
pg_restore: FATAL: invalid frontend message type 49
I tried using pg_restore version 14 with the same outcome.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | Andronicus |