Re: GiST VACUUM - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: GiST VACUUM
Date
Msg-id CDCAACB6-04F6-45C9-85E9-389B913F92E9@yandex-team.ru
Whole thread Raw
In response to Re: GiST VACUUM  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: GiST VACUUM
List pgsql-hackers

> 27 июня 2019 г., в 16:38, Heikki Linnakangas <hlinnaka@iki.fi> написал(а):
>
> I haven't done any testing on this yet. Andrey, would you happen to have an environment ready to test this?

Patches do not deadlock and delete pages on "rescan test" - setup that we used to detect "left jumps" in during
developmentof physical vacuum. check-world is happy on my machine. 
I really like that now there is GISTDeletedPageContents and we do not just cast *(FullTransactionId *)
PageGetContents(page).

But I have stupid question again, about this code:


https://github.com/x4m/postgres_g/commit/096d5586537d29ff316ca8ce074bbe1b325879ee#diff-754126824470cb8e68fd5e32af6d3bcaR417

        nextFullXid = ReadNextFullTransactionId();
            diff = U64FromFullTransactionId(nextFullXid) -
                U64FromFullTransactionId(latestRemovedFullXid);
            if (diff < MaxTransactionId / 2)
            {
                TransactionId latestRemovedXid;

                // sleep(100500 hours); latestRemovedXid becomes xid from future

                latestRemovedXid = XidFromFullTransactionId(latestRemovedFullXid);
                ResolveRecoveryConflictWithSnapshot(latestRemovedXid,
                                                    xlrec->node);
            }

Do we have a race condition here? Can latestRemovedXid overlap and start to be xid from future?
I understand that it is purely hypothetical, but still latestRemovedXid is from ancient past already.

Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
Next
From: Robert Haas
Date:
Subject: Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)