Horton

Re: GiST VACUUM

x4mmm@yandex-team.ru

View thread View on postgr.es
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Michael Paquier <michael@paquier.xyz>, Thomas Munro <thomas.munro@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Костя Кузнецов <chapaev28@ya.ru>
Date: 2019-06-25T09:38:43Z
Lists: 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 2 billion XIDs.
I feel a little uncomfortable with number 0x7fffffff right in code.

Thanks!

Best regards, Andrey Borodin.

Commits

  1. Use full 64-bit XID for checking if a deleted GiST page is old enough.

  2. Refactor checks for deleted GiST pages.

  3. Delete empty pages during GiST VACUUM.

  4. Scan GiST indexes in physical order during VACUUM.

  5. Prevent GIN deleted pages from being reclaimed too early