Re: Yet another fast GiST build - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Yet another fast GiST build
Date
Msg-id 075a990d-5a0f-1f62-8914-9ff13924e152@iki.fi
Whole thread Raw
In response to Re: Yet another fast GiST build  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Lift line-length limit for pg_service.conf
Next
From: Dilip Kumar
Date:
Subject: Re: Logical replication from PG v13 and below to PG v14 (devel version) is not working.