Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding
Date
Msg-id 0B9F7E26-2C0F-43E7-A0C5-FB84DA1163DB@yandex-team.ru
Whole thread Raw
In response to Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Krasiyan Andreev
Date:
Subject: Re: Implement for window functions
Next
From: Zhihong Yu
Date:
Subject: Re: Implement for window functions