Re: backend crash on DELETE, reproducible locally

From: Ondřej Bouda <obouda(at)email(dot)cz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: backend crash on DELETE, reproducible locally
Date: 2018-11-06 21:37:32
Message-ID: fc1fde8f-2e1d-3f8d-a583-82ba383c7fd2@email.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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

Creating a new index is wrong, too:

# CREATE INDEX schedulecard_overlap_idx2
ON public.schedulecard USING gist
(scheduletemplate_id, (period_day::integer % 7), timerange)
WITH (recheck_on_update = FALSE);

ERROR: unrecognized parameter "recheck_on_update"

It only succeeds if not USING gist:

# CREATE INDEX schedulecard_overlap_idx2
ON public.schedulecard
(scheduletemplate_id, (period_day::integer % 7), timerange)
WITH (recheck_on_update = FALSE);

CREATE INDEX

Is there any other workaround for a gist index, please?
Maybe we will just drop the index until the bug gets fixed - better slow
queries than crashing servers...

Thanks,
Ondřej Bouda

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2018-11-06 21:47:20 Re: backend crash on DELETE, reproducible locally
Previous Message Bruno Lavoie 2018-11-06 21:31:08 Re: why select count(*) consumes wal logs

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2018-11-06 21:43:38 Re: First-draft release notes for back-branch releases
Previous Message Jonah H. Harris 2018-11-06 21:35:53 Re: Disallow setting client_min_messages > ERROR?