Re: recovering from "found xmin ... from before relfrozenxid ..."
От | Andres Freund |
---|---|
Тема | Re: recovering from "found xmin ... from before relfrozenxid ..." |
Дата | |
Msg-id | 20200714194159.ux4o34m5w4ymcaih@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: recovering from "found xmin ... from before relfrozenxid ..." (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: recovering from "found xmin ... from before relfrozenxid ..."
|
Список | pgsql-hackers |
Hi, On 2020-07-14 07:51:27 -0400, Robert Haas wrote: > On Tue, Jul 14, 2020 at 3:08 AM Peter Eisentraut > <peter.eisentraut@2ndquadrant.com> wrote: > > In the meantime, if you're wizard enough to deal with this kind of > > thing, you could also clone the module from the PG14 tree and build it > > against older versions manually. > > But what if you are NOT a wizard, and a wizard is giving you > directions? Then having to build from source is a real pain. And > that's normally the situation I'm in when a customer has this issue. The "found xmin ... from before relfrozenxid ..." cases should all be fixable without needing such a function, and without it making fixing them significantly easier, no? As far as I understand your suggested solution, you need the tid(s) of these tuples, right? If you have those, I don't think it's meaningfully harder to INSERT ... DELETE WHERE ctid = .... or something like that. ISTM that the hard part is finding all problematic tuples in an efficient manner (i.e. that doesn't require one manual VACUUM for each individual block + parsing VACUUMs error message), not "fixing" those tuples. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: