Re: GiST VACUUM - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: GiST VACUUM
Date
Msg-id 6D4AAC25-CB7F-42D1-9757-D9FE3F418743@yandex-team.ru
Whole thread Raw
In response to Re: GiST VACUUM  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: GiST VACUUM
List pgsql-hackers
Hi!

Thanks for clarification, now I understand these patches better.

> 25 июня 2019 г., в 13:10, Heikki Linnakangas <hlinnaka@iki.fi> написал(а):
>
>> Also, I did not understand this optimization:
>> +    /*
>> +     * We can skip this if the page was deleted so long ago, that no scan can possibly
>> +     * still see it, even in a standby. One measure might be anything older than the
>> +     * table's frozen-xid, but we don't have that at hand here. But anything older than
>> +     * 2 billion, from the next XID, is surely old enough, because you would hit XID
>> +     * wraparound at that point.
>> +     */
>> +    nextxid = ReadNextFullTransactionId();
>> +    diff = U64FromFullTransactionId(nextxid) - U64FromFullTransactionId(latestRemovedXid);
>> +    if (diff < 0x7fffffff)
>> +        return;
>> Standby can be lagging months from primary, and, theoretically, close
>> the gap in one sudden WAL leap...
> It would still process the WAL one WAL record at a time, even if it's lagging months behind. It can't just jump over
2billion XIDs. 
I feel a little uncomfortable with number 0x7fffffff right in code.

Thanks!

Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Choosing values for multivariate MCV lists
Next
From: Amit Khandekar
Date:
Subject: Re: Minimal logical decoding on standbys