"missing chunk number 0 for toast value xxx in pg_toast_xxx" when pg_basebackup - Mailing list pgsql-general

From Ma Xinjian
Subject "missing chunk number 0 for toast value xxx in pg_toast_xxx" when pg_basebackup
Date
Msg-id 1618306690542-0.post@n3.nabble.com
Whole thread Raw
Responses Re: "missing chunk number 0 for toast value xxx in pg_toast_xxx" when pg_basebackup
Re: "missing chunk number 0 for toast value xxx in pg_toast_xxx" when pg_basebackup
List pgsql-general
Hi,

When I use pg_basebackup to backup and restore db(Let's call it A) to a
standalone instance(Let's call it B), "missing chunk number 0 for toast
value xxx in pg_toast_xxx" errors output.

PG version: 10.3
pg_basebackup command:
     /usr/pgsql-10/bin/pg_basebackup -h p-rdb-c01 -D /var/lib/pgsql/10/data
-Xs -P -n --waldir=/tmp/pg_wal
   I have mounted a disk to /tmp/pg_wal before, then I will mount the disk
to /var/lib/pgsql/10/data/pg_wal, so as to ensure completeness of wal
records during backup.
 
Since I don't want B to be a standy server, I just want it to be a
standalone server.
I removed recovery.conf, then simply start postgresql-10.service. It turned
out that postgresql-10.service
can be started successfully. But when I use this postgresql(reindex, vacumm
and so on), "missing chunk number 0 for toast value xxx in pg_toast_xxx"
errors output.

When pg_basebackup, it will store wal under pg_wal, can't postgresql work
with wal records locally?
I think primary_conninfo in recovery.conf is just used to get newer wal
records from A. Right?

I have also tested:
If I start postgresql-10.service with recovery.conf firstly, then split it
from postgresql cluster, everything works fine.

Above test seems proved that it is wal records's problem. I am really
confused.

Regards
Ma Xinjian






--
Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html



pgsql-general by date:

Previous
From: pinker
Date:
Subject: rollback previous commit if the current one fails
Next
From: luis.roberto@siscobra.com.br
Date:
Subject: Re: rollback previous commit if the current one fails