Re: [PATCH] fix GIN index search sometimes losing results

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Artur Zakirov <zaartur(at)gmail(dot)com>
Subject: Re: [PATCH] fix GIN index search sometimes losing results
Date: 2020-07-24 19:49:14
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> writes:
> ср, 22 июл. 2020 г. в 19:10, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> The other issue we have to agree on is whether we want to sneak this
>> fix into v13, or wait another year for it. I feel like it's pretty
>> late to be making potentially API-breaking changes, but on the other
>> hand this is undoubtedly a bug fix.

> I am convinced patch 0001 is necessary and enough to fix a bug, so I think
> it's very much worth adding it to v13.

Agreed, and done.

> As for 0002 I see the beauty of this change but I also see the value of
> leaving defaults as they were before.
> The change of CALC_NOT behavior doesn't seem to be a source of big changes,
> though. I'm just not convinced it is very much needed.
> The best way I think is to leave 0002 until the next version and add
> commentary in the code that this default behavior of NOT
> doing TS_EXEC_CALC_NOT is inherited from past, so basically any caller
> should set this flag (see patch 0003-add-comments-on-calc-not.

I don't think it's a great plan to make these two changes in two
successive versions. They're going to be affecting basically the
same set of outside callers, at least if you assume that every
TS_execute caller will be supplying its own callback function.
So we might as well force people to make both updates at once.
Also, if there is anyone who thinks they need "skip NOT" behavior,
this'd be a great time to reconsider.

I revised 0002 to still define a flag for skipping NOTs, but
it's not the default and is indeed unused in the core code now.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2020-07-24 19:55:01 Re: Default setting for enable_hashagg_disk
Previous Message Christophe Pettus 2020-07-24 19:35:35 Re: Row estimates for empty tables