Re: BUG #16961: Could not access status of transaction - Mailing list pgsql-bugs

From Stepan Yankevych
Subject Re: BUG #16961: Could not access status of transaction
Date
Msg-id 1618416199.969761000.ago134mu@frv53.fwdcdn.com
Whole thread Raw
In response to BUG #16961: Could not access status of transaction  (PG Bug reporting form <noreply@postgresql.org>)
Responses RE: BUG #16961: Could not access status of transaction  (Stepan Yankevych <Stepan_Yankevych@epam.com>)
List pgsql-bugs
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:      16961
Logged by:          Sergey Zhuravlev
Email address:      sergii.zhuravlev@smartnet.ua
PostgreSQL version: 13.2
Operating system:   CentOS Linux release 7.9.2009 (Core)
Description:        

Hello

Command  - LISTEN missed_trades_empty_instrument  
"
ERROR:  could not access status of transaction 1954017648
DETAIL:  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
--------------   6985716158

Parameter -  autovacuum_freeze_max_age = 200000000

pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Problem with accessing TOAST data in stored procedures
Next
From: Bruce Momjian
Date:
Subject: Re: [BUGS] BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail