Re: GiST VACUUM
От | Andrey Borodin |
---|---|
Тема | Re: GiST VACUUM |
Дата | |
Msg-id | CDCAACB6-04F6-45C9-85E9-389B913F92E9@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: GiST VACUUM (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: GiST VACUUM
|
Список | 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 по дате отправления: