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: Artur Zakirov <zaartur(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] fix GIN index search sometimes losing results
Date: 2020-07-02 16:34:00
Message-ID: 856353.1593707640@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> writes:
> чт, 2 июл. 2020 г. в 19:38, Artur Zakirov <zaartur(at)gmail(dot)com>:
>> So it seems we are losing some results with RUM as well.

> For me it is 100% predictable that unmodified RUM is still losing results
> as it is still using binary callback.

Right, that's in line with what I expected as well.

> The main my goal of saving binary legacy callback is that side callers like
> RUM will not break immediately but remain in
> existing state (i.e. losing results in some queries).

I don't really see why that should be a goal here. I think a forced
compile error, calling attention to the fact that there's something
to fix, is a good thing as long as we do it in a major release.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Cramer 2020-07-02 16:37:29 why do we allow people to create a publication before setting wal_leve
Previous Message Jaka Jančar 2020-07-02 16:30:51 Sync vs Flush