Re: GiST VACUUM
От | Andrey Borodin |
---|---|
Тема | Re: GiST VACUUM |
Дата | |
Msg-id | 6D4AAC25-CB7F-42D1-9757-D9FE3F418743@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: GiST VACUUM (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: GiST VACUUM
|
Список | 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 по дате отправления: