Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru>
Cc: Shubham Barai <shubhambaraiss(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Borodin <amborodin86(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com>
Subject: Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Date: 2018-03-28 16:53:22
Message-ID: 1f33318a-0150-7611-c1bb-fcb16b943c74@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

Attachment Content-Type Size
Predicate-Locking-in-gin-index_v9.patch text/x-patch 49.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2018-03-28 17:14:28 Re: [HACKERS] logical decoding of two-phase transactions
Previous Message Simon Riggs 2018-03-28 16:47:39 pgsql: Store 2PC GID in commit/abort WAL recs for logical decoding

Browse pgsql-www by date

  From Date Subject
Next Message Teodor Sigaev 2018-03-29 10:38:13 Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Previous Message Dmitry Ivanov 2018-03-28 15:07:43 Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)