Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding
От | Andrey Borodin |
---|---|
Тема | Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding |
Дата | |
Msg-id | 0B9F7E26-2C0F-43E7-A0C5-FB84DA1163DB@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> 9 янв. 2021 г., в 15:17, Noah Misch <noah@leadboat.com> написал(а): > >> This >> int diff_max = ((QUEUE_MAX_PAGE + 1) / 2) - 1, >> seems to be functional equivalent of >> int diff_max = ((QUEUE_MAX_PAGE - 1) / 2), > > Do you think one conveys the concept better than the other? I see now that next comments mention "(QUEUE_MAX_PAGE+1)/2", so I think there is no need to change something in a patch here. >> I'm a little bit afraid that this kind of patch can hide bugs (while potentially saving some users data). Besides thispatch seems like a useful precaution. Maybe we could emit scary warnings if SLRU segments do not stack into continuousrange? > > Scary warnings are good for an observation that implies a bug, but the > slru-truncate-t-insurance patch causes such an outcome in non-bug cases where > it doesn't happen today. In other words, discontinuous ranges of SLRU > segments would be even more common after that patch. For example, it would > happen anytime oldestXID advances by more than ~1B at a time. Uhm, I thought that if there is going to be more than ~1B xids - we are going to keep all segements forever and range stillwill be continuous. Or am I missing something? Thanks! Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: