Re: GiST VACUUM

Поиск
Список
Период
Сортировка
От Andrey Borodin
Тема Re: GiST VACUUM
Дата
Msg-id 1972C522-9019-4B9D-A6DF-3A5786688DB8@yandex-team.ru
обсуждение исходный текст
Ответ на Re: GiST VACUUM  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: GiST VACUUM
Список pgsql-hackers
Hi!

Thanks for fixing gist amcheck! The idea of using these two patches together seems so obvious now, but never actually
visitedmy mind before. 

> 4 марта 2019 г., в 18:04, Heikki Linnakangas <hlinnaka@iki.fi> написал(а):
> Thanks! As I noted at https://www.postgresql.org/message-id/2ff57b1f-01b4-eacf-36a2-485a12017f6e%40iki.fi, the test
patchleft the index corrupt. I fixed it so that it leaves behind incompletely split pages, without the corruption, see
attached.It's similar to yours, but let me recap what it does: 
>
> * Hacks gistbuild(), create 100 empty pages immediately after the root pages. They are leaked, so they won't be
reuseduntil the a VACUUM sees them and puts them to the FSM 
>
> * Hacks gistinserttuples(), to leave the split incompleted with 50% probability
>
> * In vacuum, print a line to the log whenever it needs to "jump left"
>
> I used this patch, with the attached test script that's similar to yours, but it also tries to verify that the index
returnscorrect results. It prints a result set like this: 
>
>   sum
> ---------
> -364450
>  364450
> (2 rows)
>
> If the two numbers add up to 0, the index seems valid. And you should see "RESCAN" lines in the log, to show that
jumpingleft happened. Because the behavior is random and racy, you may need to run the script many times to see both
"RESCANTRIGGERED BY NSN" and "RESCAN TRIGGERED BY FollowRight" cases. Especially the "FollowRight" case happens less
frequentlythan the NSN case, you might need to run the script > 10 times to see it. 
Great! I've repeated your tests on my machine, I observe similar frequencies of causes of rescan left jumps.

> I also tried your amcheck tool with this. It did not report any errors.
>
> Attached is also latest version of the patch itself. It is the same as your latest patch v19, except for some tiny
commentkibitzing. I'll mark this as Ready for Committer in the commitfest app, and will try to commit it in the next
coupleof days. 

That's cool! I'll work on 2nd step of these patchset to make blockset data structure prettier and less hacky.

Best regards, Andrey Borodin.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Segfault when restoring -Fd dump on current HEAD
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: query logging of prepared statements