From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Костя Кузнецов <chapaev28(at)ya(dot)ru> |
Subject: | Re: GiST VACUUM |
Date: | 2019-06-25 09:38:43 |
Message-ID: | 6D4AAC25-CB7F-42D1-9757-D9FE3F418743@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi!
Thanks for clarification, now I understand these patches better.
> 25 июня 2019 г., в 13:10, Heikki Linnakangas <hlinnaka(at)iki(dot)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 2 billion XIDs.
I feel a little uncomfortable with number 0x7fffffff right in code.
Thanks!
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Juan José Santamaría Flecha | 2019-06-25 10:00:45 | Re: BUG #15858: could not stat file - over 4GB |
Previous Message | Tomas Vondra | 2019-06-25 09:18:19 | Re: Choosing values for multivariate MCV lists |