Re: backend crash on DELETE, reproducible locally
От | Tom Lane |
---|---|
Тема | Re: backend crash on DELETE, reproducible locally |
Дата | |
Msg-id | 4375.1541540840@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: backend crash on DELETE, reproducible locally (Ondřej Bouda <obouda@email.cz>) |
Ответы |
Re: backend crash on DELETE, reproducible locally
Re: backend crash on DELETE, reproducible locally Re: backend crash on DELETE, reproducible locally Re: backend crash on DELETE, reproducible locally |
Список | pgsql-hackers |
=?UTF-8?Q?Ond=c5=99ej_Bouda?= <obouda@email.cz> writes: >> Ondřej, as a short-term workaround you could prevent the crash >> by setting that index's recheck_on_update property to false. > Thanks for the tip. I am unsuccessful using it, though: > # ALTER INDEX public.schedulecard_overlap_idx SET (recheck_on_update = > FALSE); > ERROR: unrecognized parameter "recheck_on_update" Oh, for crying out loud. That's yet a different bug. I'm not sure that it's the fault of the recheck_on_update feature proper though; it might be a pre-existing bug in the reloptions code. Looks like somebody forgot to list RELOPT_KIND_GIST in RELOPT_KIND_INDEX, but is that the fault of commit c203d6cf8 or was it busted before? regards, tom lane
В списке pgsql-hackers по дате отправления: