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
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 |