Re: ERROR: found xmin 4133102167 from before relfrozenxid 4151440783

Hi

so 13. 9. 2025 v 3:24 odesílatel Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
napsal:

> On Sat, 2025-09-13 at 06:40 +0530, Tushar Takate wrote:
> > On Sat, Sep 13, 2025 at 2:40 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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.

Regards

Pavel