Re: Ignoring BRIN for HOT udpates seems broken

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Ignoring BRIN for HOT udpates seems broken
Дата
Msg-id 20220530195758.w4hi6lfkfdektbby@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Ignoring BRIN for HOT udpates seems broken  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Список pgsql-hackers
Hi,

On 2022-05-30 17:22:35 +0200, Matthias van de Meent wrote:
> > Yeah, I think that might/should work. We could still create the HOT
> > chain, but we'd have to update the BRIN indexes. But that seems like a
> > fairly complicated change to be done this late for PG15.
> 
> Here's an example patch for that (based on a branch derived from
> master @ 5bb2b6ab). A nod to the authors of the pHOT patch, as that is
> a related patch and was informative in how this could/should impact AM
> APIs -- this is doing things similar (but not exactly the same) to
> that by only updating select indexes.
> 
> Note that this is an ABI change in some critical places -- I'm not
> sure it's OK to commit a fix like this into PG15 unless we really
> don't want to revert 5753d4ee320b.
> 
> Also of note is that this still updates _all_ summarizing indexes, not
> only those involved in the tuple update. Better performance is up to a
> different implementation.
> 
> The patch includes a new regression test based on your example, which
> fails on master but succeeds after applying the patch.

This seems like a pretty clear cut case for reverting and retrying in
16. There's plenty subtlety in this area (as evidenced by this thread and the
index/reindex concurrently breakage), and building infrastructure post beta1
isn't exactly conducive to careful analysis and testing.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Race conditions in 019_replslot_limit.pl
Следующее
От: Tom Lane
Дата:
Сообщение: Re: SQL/JSON functions vs. ECPG vs. STRING as a reserved word