Re: effective_multixact_freeze_max_age issue
От | Peter Geoghegan |
---|---|
Тема | Re: effective_multixact_freeze_max_age issue |
Дата | |
Msg-id | CAH2-Wz=0ua8-L++Mb+CZOAhqAwZjBX1eA1oJEF4+0gDU9iUKjw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: effective_multixact_freeze_max_age issue (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: effective_multixact_freeze_max_age issue
|
Список | pgsql-hackers |
On Mon, Oct 24, 2022 at 7:56 AM Peter Geoghegan <pg@bowt.ie> wrote: > I don't understand what you mean. FreezeLimit *isn't* always exactly > 50 million XIDs before OldestXmin -- not anymore. In fact that's the > main benefit of this work (commit c3ffa731). That detail has changed > (and changed for the better). Though it will only be noticeable to > users when an old snapshot holds back OldestXmin by a significant > amount. I meant that the new behavior will only have a noticeable impact when OldestXmin is significantly earlier than nextXID. Most of the time there won't be any old snapshots, which means that there will only be a negligible difference between OldestXmin and nextXID when things are operating normally (OldestXmin will still probably be a tiny bit earlier than nextXID, but not enough to matter). And so most of the time the difference between the old approach and the new approach will be completely negligible; 50 million XIDs is usually a huge number (it is usually far far larger than the difference between OldestXmin and nextXID). BTW, I have some sympathy for the argument that the WARNINGs that we have here may not be enough -- we only warn when the situation is already extremely serious. I just don't see any reason why that problem should be treated as a regression caused by commit c3ffa731. The WARNINGs may be inadequate, but that isn't new. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: