Re: New strategies for freezing, advancing relfrozenxid early
От | Peter Geoghegan |
---|---|
Тема | Re: New strategies for freezing, advancing relfrozenxid early |
Дата | |
Msg-id | CAH2-Wz=VAgHL6E92Mi-jaOt_40Fj-Q5YD7n5r6P3gftgE2vdCQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: New strategies for freezing, advancing relfrozenxid early (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: New strategies for freezing, advancing relfrozenxid early
|
Список | pgsql-hackers |
On Wed, Jan 25, 2023 at 5:26 PM Andres Freund <andres@anarazel.de> wrote: > Another bad scenario: Some longrunning / hung transaction caused us to get > close to the xid wraparound. Problem was resolved, autovacuum runs. Previously > we wouldn't have frozen the portion of the table that was actively changing, > now we will. Consequence: We get closer to the "no write" limit / the outage > lasts longer. Obviously it isn't difficult to just invent a new rule that gets applied by lazy_scan_strategy. For example, it would take me less than 5 minutes to write a patch that disables eager freezing when the failsafe is in effect. > I don't see an alternative to reverting this for now. I want to see your test case before acting. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: