Hi, On 2020-07-14 15:59:21 -0400, Robert Haas wrote: > On Tue, Jul 14, 2020 at 3:42 PM Andres Freund <and...@anarazel.de> wrote: > > 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. > > I haven't tried the INSERT ... DELETE approach, but I've definitely > seen a case where a straight UPDATE did not fix the problem; VACUUM > continued failing afterwards.
The only way I can see that to happen is for the old tuple's multixact being copied forward. That'd not happen with INSERT ... DELETE. > In that case, it was a system catalog > that was affected, and not one where TRUNCATE + re-INSERT was remotely > practical. FWIW, an rewriting ALTER TABLE would likely also fix it. But obviously that'd require allow_system_table_mods... > Do you have a reason for believing that INSERT ... DELETE is going to > be better than UPDATE? It seems to me that either way you can end up > with a deleted and thus invisible tuple that you still can't get rid > of. None of the "new" checks around freezing would apply to deleted tuples. So we shouldn't fail with an error like $subject. Greetings, Andres Freund
