From: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> |
---|---|
To: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: recovering from "found xmin ... from before relfrozenxid ..." |
Date: | 2020-07-29 04:28:08 |
Message-ID: | CAE9k0PmQ-LoJQiUZ2NaJubsM8xkF5jf=XUnvdg9k-jMuXh8npw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > I think we should let VACUUM do that.
> Sometimes VACUUM will not get to these pages, because they are marked All
> Frozen.
> An possibly some tuples will get stale on this page again
>
Hmm, okay, will have a look into this. Thanks.
>
> > > Are there any caveats with concurrent VACUUM? (I do not see any, just
> asking)
> >
> > As of now, I don't see any.
> VACUUM has collection of dead item pointers. We will not resurrect any of
> them, right?
>
We won't be doing any such things.
> > > It would be good to have some checks for interrupts in safe places.
> >
> > I think I have already added those wherever I felt it was required. If
> you feel it's missing somewhere, it could be good if you could point it out.
> Sorry, I just overlooked that call, everything is fine here.
>
Okay, thanks for confirming.
> > > Also, I'd be happy if we had something like "Restore this tuple iff
> this does not break unique constraint". To do so we need to sort tids by
> xmin\xmax, to revive most recent data first.
> >
> > I didn't get this point. Could you please elaborate.
> You may have 10 corrupted tuples for the same record, that was updated 9
> times. And if you have unique constraint on the table you may want to have
> only latest version of the row. So you want to kill 9 tuples and freeze 1.
>
Okay, in that case, users need to pass the tids of the 9 tuples that they
want to kill to heap_force_kill function and the tid of the tuple that they
want to be marked as frozen to heap_force_freeze function. Just to inform
you that this tool is not used to detect any data corruption, it is just
meant to remove/clean the corrupted data in a table so that the operations
like vacuum, pg_dump/restore succeeds. It's users responsibility to
identify the corrupted data and pass its tid to either of these functions
as per the requirement.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Sharma | 2020-07-29 04:37:49 | Re: recovering from "found xmin ... from before relfrozenxid ..." |
Previous Message | Masahiko Sawada | 2020-07-29 04:27:07 | Re: [PATCH] Tab completion for VACUUM of partitioned tables |