On 27/01/2016 10:27, Fujii Masao wrote:
> On Mon, Jan 25, 2016 at 3:54 PM, Jeff Janes <jeff.ja...@gmail.com>
>> On Wed, Jan 20, 2016 at 6:17 AM, Fujii Masao
>> <masao.fu...@gmail.com> wrote:
>>> On Sat, Jan 16, 2016 at 7:42 AM, Julien Rouhaud
>>> <julien.rouh...@dalibo.com> wrote:
>>>> On 15/01/2016 22:59, Jeff Janes wrote:
>>>>> On Sun, Jan 10, 2016 at 4:24 AM, Julien Rouhaud
>>>>> <julien.rouh...@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,
>>> 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,
>>> ISTM that AccessShareLock is not safe when updating the pending
>>> list and GIN index main structure. Probaby we should use
>> 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"
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
- 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
+ option disabled, the cleanup does not happen and the return value
+ because the index doesn't have a pending list.
Otherwise, I don't see any problem on this version.
http://dalibo.com - http://dalibo.org
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: