12.2 reporting ERROR: cannot freeze
>> committed xmax
>> using Red Hat Enterprise Linux 8.9.
>>
>> What is the recommended to find any bug fixes that the version 12.2 had
>> that could have caused this error.
>>
>
> https://www.postgresql.org/docs/releas
On Thu, May 23, 2024 at 9:41 AM bruno da silva wrote:
> Hello,
> I have a deployment with PG 12.2 reporting ERROR: cannot freeze committed
> xmax
> using Red Hat Enterprise Linux 8.9.
>
> What is the recommended to find any bug fixes that the version 12.2 had
> that could h
Hello,
I have a deployment with PG 12.2 reporting ERROR: cannot freeze committed
xmax
using Red Hat Enterprise Linux 8.9.
What is the recommended to find any bug fixes that the version 12.2 had
that could have caused this error.
Could this error be caused by OS/Hardware related issues?
Thanks
619"
automatic vacuum of table "dbnamexx.pg_catalog.pg_class"automatic vacuum of
table "dbnamexx.ibent.loginsession_old"automatic vacuum of table
"dbnamexx.pg_toast.pg_toast_2619"
The problem is on the user tables:
vacuum schema.tbl1_old;
ERROR: cannot freez
Hi Alvaro, glad to hear from you!
This database is relatevely young, it was initdb'ed about a year ago or so and
it was initially at 10.x. I don't know the exact minor version but the major
version was 10 for sure.
The problematic row is actually visible:
SELECT COUNT(*) FROM pg_proc WHER
One thing I forgot is that these XIDs are fairly old, perhaps dating
back to when this database was freshly initdb'd if there has been no XID
wraparound. In that case you were probably running a version much older
than 10.14 when they were written. Do you happen to know when did you
initdb this,
Hi Sasha
On 2021-Jul-14, Sasha Aliashkevich wrote:
> lp | ctid | xmin| xmax | xmax_is_lock | xmax_committed |
> xmax_rolled_back | xmax_multixact
> +-+---+--+--++--+
> 19 | (75,21) | 571 | 572
Hi,
Few weeks ago at one of the databases we started to observe the following error
in Postgresql logs:
ERROR: cannot freeze committed xmax 572
For the note it's Postgresql 10.14 running on RHEL:
ve