Re: Yet another fast GiST build

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Yet another fast GiST build
Дата
Msg-id 075a990d-5a0f-1f62-8914-9ff13924e152@iki.fi
обсуждение исходный текст
Ответ на Re: Yet another fast GiST build  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 21/09/2020 02:06, Tom Lane wrote:
> Justin Pryzby <pryzby@telsasoft.com> writes:
>> This also appears to break checksums.

Fixed, thanks for the report!

> I was wondering about that, because the typical pattern for use of
> smgrextend for indexes seems to be
> 
>     RelationOpenSmgr(rel);
>     PageSetChecksumInplace(page, lastblock);
>     smgrextend(rel->rd_smgr, MAIN_FORKNUM, lastblock, zerobuf.data, false);
> 
> and gist_indexsortbuild wasn't doing either of the first two things.
> 
> gist_indexsortbuild_flush_ready_pages looks like it might be
> a few bricks shy of a load too.  But my local CLOBBER_CACHE_ALWAYS
> run hasn't gotten to anything except the pretty-trivial index
> made in point.sql, so I don't have evidence about it.

I added a RelationOpenSmgr() call there too, although it's not needed 
currently. It seems to be enough to do it before the first smgrextend() 
call. But if you removed or refactored the first call someohow, so it 
was not the first call anymore, it would be easy to miss that you'd 
still need the RelationOpenSmgr() call there. It's more consistent with 
the code in nbtsort.c now, too.

- Heikki



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

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Lift line-length limit for pg_service.conf
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: Logical replication from PG v13 and below to PG v14 (devel version) is not working.