Re: GIN data corruption bug(s) in 9.6devel
От | Tomas Vondra |
---|---|
Тема | Re: GIN data corruption bug(s) in 9.6devel |
Дата | |
Msg-id | 11468c88-8c60-d2ab-b0eb-e88fda39f2bd@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: GIN data corruption bug(s) in 9.6devel (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: GIN data corruption bug(s) in 9.6devel
|
Список | pgsql-hackers |
Hi, On 04/04/2016 02:25 PM, Tomas Vondra wrote: > On 04/04/2016 02:06 PM, Teodor Sigaev wrote: >>> The above-described topic is currently a PostgreSQL 9.6 open item. >>> Teodor, >>> since you committed the patch believed to have created it, you own >>> this open >>> item. If that responsibility lies elsewhere, please let us know whose >>> responsibility it is to fix this. Since new open items may be >>> discovered at >>> any time and I want to plan to have them all fixed well in advance of >>> the ship >>> date, I will appreciate your efforts toward speedy resolution. Please >>> present, within 72 hours, a plan to fix the defect within seven days >>> of this >>> message. Thanks. >> >> I'm waiting of Tomas testing. Suppose, it isn't possible now? so, will >> do myself, after that I will publish results. > > Ah, damn. This completely slipped from my TODO list. I'll rerun the > tests either today or tomorrow, and report the results here. So, I've done some testing on the patch, and in short it seems fine to me. It fixes the bug (no data corruption observed), and the performance seems fine too. I've tested the v2, v3 and v3.1 of the patch, to see if there are any differences. The v2 no longer applies, so I tested it on ee943004. The following table shows the total duration of the data load, and also sizes of the two GIN indexes. duration (sec) subject body --------------------------------------------------------------- v2 1290 23 MB 684 MB v3 1360 24 MB 487 MB v3.1 1360 24 MB 488 MB So, looks good to me. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: