Postgres, I am getting ERROR: unexpected chunk number 0 (expected 1) for toast value 12599063 in pg_toast_16687 - postgresql

I am new to Postgres and one of my reports that is using select and extracting JSON return the following error.
ERROR: unexpected chunk number 0 (expected 1) for toast value 12599063 in pg_toast_16687
SQL state: XX000
I do not know how to proceed in fixing my query. Any idea?

Run this command:
select reltoastrelid::regclass from pg_class where relname = 'table_name';
Where the table_name is where the error occur. Then check the result if it is the same toast# like pg_toast.pg_toast_XXXXX. Mine happen to be 16687
Then run these commands to reindex:
REINDEX table table_name;
REINDEX table pg_toast.pg_toast_16687;
VACUUM analyze table_name;

That is data corruption:
restore from backup
upgrade to the latest PostgreSQL minor release
check the hardware

Related

data corrupted in postgres - right sibling's left-link doesn't match: block 9550 links to 12028 instead of expected 12027 in index "log_attach_id_idx"

I am new to Postgres and we are using it for tests reports, we had an issue with our environment that entered duplicate keys to one of the table and since then we are getting this message when trying to run migration scripts:
error: migration failed: right sibling's left-link doesn't match: block 9550 links to 12028 instead of expected 12027 in index "log_attach_id_idx" in line 0: UPDATE log SET project_id = (SELECT project_id FROM item_project WHERE item_project.item_id=log.item_id LIMIT 1); (details: pq: right sibling's left-link doesn't match: block 9550 links to 12028 instead of expected 12027 in index "log_attach_id_idx")
I tried to run pg_dump and got this error:
pg_dump: error: query was: SELECT pg_catalog.pg_get_viewdef('457544'::pg_catalog.oid) AS viewdef
pg_dumpall: error: pg_dump failed on database "reportportal", exiting
Can anyone help here?
Restore your backup, and research what parameters you changed and what you did to end up with data corruption in the first place.

How to backup/recover database after a "missing chunk number 0" message?

PostgreSQL. When I try to backup the database via pgAdmin, I get error
pg_dump: error: Dumping the contents of table "filearchives" failed: PQgetResult() failed.
pg_dump: error: Error message from server: ������: missing chunk number 0 for toast value 1508672 in pg_toast_1245716
pg_dump: error: The command was: COPY public.filearchives (id, usedtime, docid, options, filesize, filename, stream) TO stdout;"
I followed these instructions: https://gist.github.com/supix/80f9a6111dc954cf38ee99b9dedf187a
There were similar errors for REINDEX and VACUUM on the main table (filearchives), but nothing for pg_toast and I was able to select all rows in the main table (filearchives), while there was supposed to be "Corrupted chunk read!".
When I do it via psql, there is no error message, but the backup is incomplete.
The database itself is working fine at the moment.
How to recover the database without removing records? Is there a way to create a backup?

PostGIS doesn't work after update in Manjaro

I recently ran a full update on my Manjaro-System, afterwards, when I tried to run a small script I use to start and automatically save my Postgres-DB I get the following error in the shell.
pg_dump: error: query failed: ERROR: could not load library
"/usr/lib/postgresql/postgis-3.so": /usr/lib/postgresql/postgis-3.so:
undefined symbol: list_make1_impl
pg_dump: error: query was:
SELECT
a.attnum,
a.attname,
a.atttypmod,
a.attstattarget,
a.attstorage,
t.typstorage,
a.attnotnull,
a.atthasdef,
a.attisdropped,
a.attlen,
a.attalign,
a.attislocal,
pg_catalog.format_type(t.oid, a.atttypmod) AS atttypname,
a.attgenerated,
CASE WHEN a.atthasmissing AND NOT a.attisdropped THEN a.attmissingval ELSE null END AS attmissingval,
a.attidentity,
pg_catalog.array_to_string(ARRAY(SELECT pg_catalog.quote_ident(option_name) || ' ' || pg_catalog.quote_literal(option_value) FROM pg_catalog.pg_options_to_table(attfdwoptions) ORDER BY option_name), E',
') AS attfdwoptions,
CASE WHEN a.attcollation <> t.typcollation THEN a.attcollation ELSE 0 END AS attcollation,
array_to_string(a.attoptions, ', ') AS attoptions
FROM pg_catalog.pg_attribute a LEFT JOIN pg_catalog.pg_type t ON a.atttypid = t.oid
WHERE a.attrelid = '18597'::pg_catalog.oid AND a.attnum > 0::pg_catalog.int2
ORDER BY a.attnum
Also, when I start the database in pgAdmin I can open all the tables except the one which holds the geography-column, which needs PostGIS. It shows me the following error instead:
ERROR: could not load library /usr/lib/postgresql/postgis-3.so: /usr/lib/postgresql/postgis-3.so: undefined symbol: list_make1_impl SQL state: 58P01
Apparently something in the proj-package is messed up. According to this thread, it could have something to do with this package being installed several times. However, I reinstalled proj manually, from the Official Repo as well as from the AUR each time with a different version and cleaned the old version every time. The error is still there.
Currently the version setup is:
QGIS: Version 3.16.5
Postgres: Version 12.6-1
PostGIS: Version 3.0.3-1
proj: Version 6.3.2-1
Manjaro: KDE-Plasma 5.21.3
Kernel: 4.19.183-1-Manjaro
Does anyone have a solution for this?
Thanks to the local Linux User Group I found a solution to the problem. It turned out, that PostGIS was updated in the background and the new version did not correspond with PostgreSQL 12.6 any more. Since PostGIS was already installed, it did not show me this but the error message above instead.
To check if PostGIS is still compatible with PostgreSQL, I create a new database and then tried to add the PostGIS extension. I got the following message, that cleared things up:
test=# CREATE EXTENSION postgis;
ERROR: could not open extension control file "/usr/share/postgresql/extensionpost.control": No such file or directory
test=# CREATE EXTENSION postgis;
ERROR: PostGIS built for PostgreSQL 13.0 cannot be loaded in PostgreSQL 12.6
So I updated PostgreSQL, set up a new database cluster and used pg_restore on the last .sql from my automatic pg_dump to recreate the database. It now works as before again.

Attempted to delete invisible tuple + Postgres

I have system where we perform large number of inserts and updates query(something upsert as well)
I see occasionally error on my logs that states ..
PG::ObjectNotInPrerequisiteState: ERROR: attempted to delete invisible tuple
INSERT INTO call_records(plain_crn,efd,acd,slt,slr,ror,raw_processing_data,parsed_json,timestamp,active,created_at,updated_at) VALUES (9873,2016030233,'R',0,0,'PKC01','\x02000086000181f9000101007 ... ')
What I fail to understand even when no (delete) query is performed (the above error appear on insert clause) yet the error was thrown.
I have been googling around this issue but no conclusive evidence of why this happen.
Version of Postgres.
database=# select version();
version
--------------------------------------------------------------------------------------------------------------
PostgreSQL 9.5.2 on x86_64-apple-darwin14.5.0, compiled by Apple LLVM version 7.0.0 (clang-700.1.76), 64-bit
(1 row)
Any Clue ??

PostgreSQL hangs while executing DDL without log message

I have Postgresql-9.2.10 on CentOS.
I experience the following error:
DETAIL: Multiple failures --- write error might be permanent.
ERROR: could not open file "pg_tblspc / 143862353 / PG_9.2_201204301 / 16439 / 199534370_fsm": No such file or directory
This happens since I stopped the PostgreSQL service, ran pg_resetxlog and started the service. The logs in pg_log look good, and the service is listed without any problem.
DML works well , but not a DDL statement like CREATE TABLE, otherwise an error message is thrown or nothing is visible in the logs in pg_log.
If I try to create a table, there is no reaction, and it looks like the statement is blocked by a lock.
So I tried the following query to look for locks:
SELECT blocked_locks.pid AS blocked_pid,
blocked_activity.usename AS blocked_user,
blocking_locks.pid AS blocking_pid,
blocking_activity.usename AS blocking_user,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.granted;
You probably corrupted the PostgreSQL cluster with pg_resetxlog. How exactly did you run the command?
I would restore from the last good backup.