Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Date
Msg-id 1f33318a-0150-7611-c1bb-fcb16b943c74@sigaev.ru
Whole thread Raw
In response to Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Dmitry Ivanov <d.ivanov@postgrespro.ru>)
Responses Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Teodor Sigaev <teodor@sigaev.ru>)
Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
Hi!

I slightly modified test for clean demonstration of difference between 
fastupdate on and off. Also I added CheckForSerializableConflictIn() to 
fastupdate off codepath, but only in case of non-empty pending list.

The next question what I see: why do not we lock entry leaf pages in some cases? 
As I understand, scan should lock any visited page, but now it's true only for 
posting tree. Seems, it also should lock pages in entry tree because concurrent 
procesess could add new entries which could be matched by partial search, for 
example. BTW, partial search (see collectMatchBitmap()) locks correctly entry 
tree, but regular startScanEntry() doesn't lock entry page in case of posting 
tree, only in case of posting list.


Dmitry Ivanov wrote:
>> I'd like to see fastupdate=on in test too, now tests cover only case
>> without fastupdate. Please, add them.
> 
> Here's a couple of tests for pending list (fastupdate = on).
> 

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/

Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Re: csv format for psql
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions