On Sat, 2025-09-13 at 06:40 +0530, Tushar Takate wrote: > On Sat, Sep 13, 2025 at 2:40 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote: > > On Fri, 2025-09-12 at 22:09 +0530, Tushar Takate wrote: > > > PostgreSQL version: 15.12 > > > Disk type: RAID5 > > > OS: RHEL 8.10 > > > > > > Error/Issue : > > > > > > vacuumdb: error: processing of database "live_order_us_db" failed: ERROR: found xmin 4133102167 from before relfrozenxid 4151440783 > > > > > > 2025-09-11 02:29:58.888 UTC,,,2362287,,68c233e1.240hbf,1,,2025-09-11 02:28:49 UTC,122/46371006,0,ERROR,XX001,"found xmin 4133102167 from before relfrozenxid 4151440783",,,,,"while scanning block 5821149 offset 5 of relation ""public.order"" > > > 2025-09-11 02:40:50.361 UTC,"prod_user_ap","live_order_us_db",2375672,"127.0.0.1:59344",68c2342b.243ff8,4,"VACUUM",2025-09-11 02:30:03 UTC,169/38875732,0,ERROR,XX001,"found xmin 4133102167 from before relfrozenxid 4151440783",,,,,"while scanning block 5821149 offset 5 of relation ""public.order""","VACUUM (VERBOSE, ANALYZE) public.order;",,,"vacuumdb","client backend",,-5528190995457849841 > > > > That is probably caused by a PostgreSQL bug; you can get rid of the message > > In which version can we expect the fix for it? Also, can you please help to understand > which specific condition or scenario is triggering this PostgreSQL error and skipping > to freeze xmin?
I *believe* there must be a bug that causes that problem, because I have seen that error reported often enough that I don't think it can be attributed to hardware errors. Unfortunately, I think that nobody knows how it happens, so we cannot fix it.
> > by creating the "pg_surgery" extension and running > > > > SELECT heap_force_freeze('public.order'::regclass, '{(5821149,5)}'::tid[]); > > I agree we can run pg_surgery , but the question is how safe it is to run for large and mission-critical tables over 200GB. > From pg_surgery doc: These functions are unsafe by design and using them may corrupt (or further corrupt) your database
It is dangerous, and that has nothing to do with the size of the table. If you do the wrong thing with that knife, you can cause more problems than you fix.
I got this error after using pg_repack and following the upgrade. So maybe there can be more factors.
