RE: BUG #16961: Could not access status of transaction
От | Stepan Yankevych |
---|---|
Тема | RE: BUG #16961: Could not access status of transaction |
Дата | |
Msg-id | VE1PR03MB531295B1BDCFE422441B15FD92499@VE1PR03MB5312.eurprd03.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: BUG #16961: Could not access status of transaction (Stepan Yankevych <stepya@ukr.net>) |
Ответы |
Re: BUG #16961: Could not access status of transaction
|
Список | pgsql-bugs |
The database was rebooted and the issue disappeared
Hopefully it was one time issue.
From: Stepan Yankevych <stepya@ukr.net>
Sent: Wednesday, April 14, 2021 7:12 PM
To: sergii.zhuravlev@smartnet.ua; pgsql-bugs@lists.postgresql.org
Cc: sergii.zhuravlev@smartnet.ua
Subject: Re: BUG #16961: Could not access status of transaction
Hi Guys!
Let me clarify few things things about the issue.
The issue happening each morning when application starts on the production DataBase during about a month.
Always the same transaction id is mentioned in the error (1954017648)
We tried to do UNLISTEN - no changes. the same issue.
LISTEN works good for any other channels.
Can it be related to some hanged transaction? 1954017648? (for example while some network interruption)
Is it possible to kill/clean it somehow without DB restart?
Can it be related to some non-vacuumed system table or so?
Any other ideas?
Thanks!
--- Original message ---
From: "PG Bug reporting form" <noreply@postgresql.org>
Date: 13 April 2021, 18:50:26
The following bug has been logged on the website:Bug reference: 16961Logged by: Sergey ZhuravlevEmail address: sergii.zhuravlev@smartnet.uaPostgreSQL version: 13.2Operating system: CentOS Linux release 7.9.2009 (Core)Description:HelloCommand - LISTEN missed_trades_empty_instrument"ERROR: could not access status of transaction 1954017648DETAIL: Could not open file "pg_xact/0747": No such file or directory.STATEMENT: LISTEN missed_trades_empty_instrument"Current transaction# select txid_current();txid_current--------------6985716158Parameter - autovacuum_freeze_max_age = 200000000
В списке pgsql-bugs по дате отправления: