Re: Reduce amount of WAL generated by CREATE INDEX for gist, gin andsp-gist - Mailing list pgsql-hackers

From Andrey Lepikhov
Subject Re: Reduce amount of WAL generated by CREATE INDEX for gist, gin andsp-gist
Date
Msg-id 6b6def86-8a2c-d3ec-c83f-c68309f5823d@postgrespro.ru
Whole thread Raw
In response to Re: Reduce amount of WAL generated by CREATE INDEX for gist, gin andsp-gist  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers

On 26/03/2019 15:59, Heikki Linnakangas wrote:
> On 26/03/2019 11:29, Andrey Lepikhov wrote:
>> On 25/03/2019 15:21, Heikki Linnakangas wrote:
>>> Hmm. When do we create all-zero pages during index build? That seems
>>> pretty surprising.
>>
>> GIST uses buffered pages. During GIST build it is possible (very rarely)
>> what no one index tuple was written to the block page before new block
>> was allocated. And the page has become an all-zero page.
>> You can't have problems in the current GIST code, because it writes into
>> the WAL only changed pages.
> 
> Looking at the code, I don't see how that could happen. The only place 
> where the GiST index file is extended is in gistNewBuffer(), and all 
> callers of that initialize the page immediately after the call. What am 
> I missing?
Sorry, This issue was found in SP-GiST AM. You can show it:
1. Apply v2 version of the patch set (see attachment).
2. In the generic_log_relation() routine set logging on PageIsNew(buf)
3. Run script t1.sql (in attachment).

This problem can be resolved by calling MarkBufferDirty() after 
SpGistInitBuffer() in the allocNewBuffer() routine. But in this case we 
will write to the WAL more pages than necessary.
To avoid it in the patch '0001-Relation-into-WAL-function' I do not 
write new pages to the WAL.

Attached patch set is not final version. It is needed for demonstration 
of 'all-zero pages' issue only. The sentence for the direct use of 
XLOG_FPI records will be considered in v3.

-- 
Andrey Lepikhov
Postgres Professional
https://postgrespro.com
The Russian Postgres Company

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: speeding up planning with partitions
Next
From: Filip Rembiałkowski
Date:
Subject: Re: dropdb --force