Re: recovering from "found xmin ... from before relfrozenxid ..."
От | Tom Lane |
---|---|
Тема | Re: recovering from "found xmin ... from before relfrozenxid ..." |
Дата | |
Msg-id | 2782922.1594688323@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: recovering from "found xmin ... from before relfrozenxid ..." (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: recovering from "found xmin ... from before relfrozenxid ..."
Re: recovering from "found xmin ... from before relfrozenxid ..." |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > Oh, I hadn't realized that limitation. That would be good to fix. It > would be even better, I think, if we could have VACUUM proceed with > the rest of vacuuming the table, emitting warnings about each > instance, instead of blowing up when it hits the first bad tuple, but > I think you may have told me sometime that doing so would be, uh, less > than straightforward. We probably should refuse to update > relfrozenxid/relminmxid when this is happening, but I *think* it would > be better to still proceed with dead tuple cleanup as far as we can, > or at least have an option to enable that behavior. I'm not positive > about that, but not being able to complete VACUUM at all is a FAR more > urgent problem than not being able to freeze, even though in the long > run the latter is more severe. +1 for proceeding in this direction, rather than handing users tools that they *will* hurt themselves with. The more that I think about it, the more I think that the proposed functions are tools for wizards only, and so I'm getting hesitant about having them in contrib at all. We lack a better place to put them, but that doesn't mean they should be there. regards, tom lane
В списке pgsql-hackers по дате отправления: