Horton

Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding

x4mmm@yandex-team.ru

View thread View on postgr.es
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Noah Misch <noah@leadboat.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2021-01-09T15:25:39Z
Lists: 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 this patch seems like a useful precaution. Maybe we could emit scary warnings if SLRU segments do not stack into continuous range?
> 
> 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 still will be continuous. Or am I missing something?

Thanks!

Best regards, Andrey Borodin.

Commits

  1. Prevent excess SimpleLruTruncate() deletion.

  2. Fix unlinking of SLRU segments.

  3. Defer flushing of SLRU files.

  4. Change XID and mxact limits to warn at 40M and stop at 3M.