Обсуждение: BUG #17528: ERROR: could not access status of transaction 1997627701

Поиск
Список
Период
Сортировка

BUG #17528: ERROR: could not access status of transaction 1997627701

От
PG Bug reporting form
Дата:
The following bug has been logged on the website:

Bug reference:      17528
Logged by:          Evgeniy Yanchuk
Email address:      ev.yanchuk.s@gmail.com
PostgreSQL version: 10.19
Operating system:   CentOS Linux release 7.7.1908 (Core)
Description:

Hello.
I've found on our server (PostgreSQL 10.19 on x86_64-pc-linux-gnu, compiled
by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit)

2022-06-21 09:08:08.291 MSK [34331:44/99061] [u178-01] [local]
10.201.14.125:10081 : Check.Finish ERROR:  could not access status of
transaction 1997627701
2022-06-21 09:08:08.291 MSK [34331:44/99061] [u178-01] [local]
10.201.14.125:10081 : Check.Finish DETAIL:  Could not open file
"pg_xact/0771": No such file or directory.
2022-06-21 09:08:08.291 MSK [34331:44/99061] [u178-01] [local]
10.201.14.125:10081 : Check.Finish STATEMENT:

I created the file "pg_xact/0771" using the command "dd if=/dev/zero
of=/var/lib/pgsql/10/data/pg_xact/0771 bs=256k count=1", but the error
reappeared after a while.

Restarting postgresql.service didn't help either.

Thanks, Evgeniy


Re: BUG #17528: ERROR: could not access status of transaction 1997627701

От
Andrey Borodin
Дата:

> On 22 Jun 2022, at 08:34, PG Bug reporting form <noreply@postgresql.org> wrote:
>
> Hello.
> I've found on our server (PostgreSQL 10.19 on x86_64-pc-linux-gnu, compiled
> by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit)
>

It seems you have encountered data corruption. This might be a result of some different causes. Can you please describe
moredetails and history of your installation? 
Do you update your system? Was it running on versions before 10.16? Somewhat related bug was fixed, but AFAIR it was
onlyreproducible only if the system is running near xid wraparound regularly. 
Does your block storage feels OK? Are data_checksums enabled?
Can you check installation with amcheck and heapcheck?
Do you have backups? If so - can you bisect when the corruption first appeared?

You can try to fix a copy of the cluster with tools like pg_surgery or pg_dirty_hands.

Best regards, Andrey Borodin.