Subject: Re: GIN pending list clean up exposure to SQL
To: Fujii Masao <masao.fujii@gmail.com>, Jeff Janes <jeff.janes@gmail.com>
References: 
 <CAMkU=1x8zFkpfnozXyt40zmR3Ub_kHu58LtRmwHUKRgQss7=iQ@mail.gmail.com>
 <CAJGNTeNVBMDzxwi=QaJWbeVequf1oENF9GbFaRMfny9H6ic_Ng@mail.gmail.com>
 <CAMkU=1xdv5n8w2-n4j_ysXy6eRd69XhWiGrdxQbqDjWEpBavww@mail.gmail.com>
 <CAMkU=1wEzVkxDJSQe5gbwb7AQ7zMi3D7mr-XMQBoyPzUnzpSpQ@mail.gmail.com>
 <56924D75.7060801@dalibo.com>
 <CAMkU=1w0z86n=+N1yFfKx4-wrO1m6M9XvEFBhV6TQmV4sK1waw@mail.gmail.com>
 <569975CD.3070103@dalibo.com>
 <CAHGQGwH=M1BAEJPQdpJjCneqwg8Xa+P8SB+ZsvhVwH6gL2J46w@mail.gmail.com>
 <CAMkU=1yuEarKAZsMqcZLWHy0hbgwhw+BRj6kOoo0EHVS=okVnA@mail.gmail.com>
 <CAHGQGwFcOGLDh7xOnXWH6Na_bsUB+=rGdcOCTXhC2=VwLARrpQ@mail.gmail.com>
Cc: Jaime Casanova <jaime.casanova@2ndquadrant.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
From: Julien Rouhaud <julien.rouhaud@dalibo.com>
Message-ID: <56A92EA2.9000906@dalibo.com>
Date: Wed, 27 Jan 2016 21:54:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
 <CAHGQGwFcOGLDh7xOnXWH6Na_bsUB+=rGdcOCTXhC2=VwLARrpQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 27/01/2016 10:27, Fujii Masao wrote:
> On Mon, Jan 25, 2016 at 3:54 PM, Jeff Janes <jeff.janes@gmail.com>
> wrote:
>> On Wed, Jan 20, 2016 at 6:17 AM, Fujii Masao
>> <masao.fujii@gmail.com> wrote:
>>> On Sat, Jan 16, 2016 at 7:42 AM, Julien Rouhaud 
>>> <julien.rouhaud@dalibo.com> wrote:
>>>> On 15/01/2016 22:59, Jeff Janes wrote:
>>>>> On Sun, Jan 10, 2016 at 4:24 AM, Julien Rouhaud 
>>>>> <julien.rouhaud@dalibo.com> wrote:
>>>> 
>>>> All looks fine to me, I flag it as ready for committer.
>>> 
>>> When I compiled the PostgreSQL with the patch, I got the
>>> following error. ISTM that the inclusion of pg_am.h header file
>>> is missing in ginfast.c.
>> 
>> Thanks.  Fixed.
>> 
>>> gin_clean_pending_list() must check whether the server is in
>>> recovery or not. If it's in recovery, the function must exit
>>> with an error. That is, IMO, something like the following check
>>> must be added.
>>> 
>>> if (RecoveryInProgress()) ereport(ERROR,
>>> 
>>> (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), 
>>> errmsg("recovery is in progress"), errhint("GIN pending list
>>> cannot be cleaned up during recovery.")));
>>> 
>>> It's better to make gin_clean_pending_list() check whether the
>>> target index is temporary index of other sessions or not, like
>>> pgstatginindex() does.
>> 
>> I've added both of these checks.  Sorry I overlooked your early
>> email in this thread about those.
>> 
>>> 
>>> +    Relation    indexRel = index_open(indexoid,
>>> AccessShareLock);
>>> 
>>> ISTM that AccessShareLock is not safe when updating the pending
>>> list and GIN index main structure. Probaby we should use
>>> RowExclusiveLock?
>> 
>> Other callers of the ginInsertCleanup function also do so while 
>> holding only the AccessShareLock on the index.  It turns out
>> that there is a bug around this, as discussed in "Potential GIN
>> vacuum bug" 
>> (http://www.postgresql.org/message-id/flat/CAMkU=1xALfLhUUohFP5v33RzedLVb5aknNUjcEuM9KNBKrB6-Q@mail.gmail.com)
>>
>>
>> 
But, that bug has to be solved at a deeper level than this patch.
>> 
>> I've also cleaned up some other conflicts, and chose a more
>> suitable OID for the new catalog function.
>> 
>> The number of new header includes needed to implement this makes
>> me wonder if I put this code in the correct file, but I don't see
>> a better location for it.
>> 
>> New version attached.
> 
> Thanks for updating the patch! It looks good to me.
> 
> Based on your patch, I just improved the doc. For example, I added
> the following note into the doc.
> 
> +    These functions cannot be executed during recovery. +    Use
> of these functions is restricted to superusers and the owner +
> of the given index.
> 
> If there is no problem, I'm thinking to commit this version.
> 

Just a detail:

+    Note that the cleanup does not happen and the return value is 0
+    if the argument is the GIN index built with <literal>fastupdate</>
+    option disabled because it doesn't have a pending list.

It should be "if the argument is *a* GIN index"

I find this sentence a little confusing, maybe rephrase like this would
be better:

-    Note that the cleanup does not happen and the return value is 0
-    if the argument is the GIN index built with <literal>fastupdate</>
-    option disabled because it doesn't have a pending list.
+    Note that if the argument is a GIN index built with
<literal>fastupdate</>
+    option disabled, the cleanup does not happen and the return value
is 0
+    because the index doesn't have a pending list.

Otherwise, I don't see any problem on this version.

Regards.

> Regards,
> 
> 
> 
> 


-- 
Julien Rouhaud
http://dalibo.com - http://dalibo.org


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers