Horton

Re: backend crash on DELETE, reproducible locally

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Ondřej Bouda <obouda@email.cz>
Cc: Ondřej Bouda <bouda@edookit.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-general@lists.postgresql.org
Date: 2018-11-06T19:45:53Z
Lists: pgsql-hackers, pgsql-general 
On 2018-Nov-06, Ondřej Bouda wrote:

> > Hmm, this one smells like c203d6cf81b4 -- haven't seen any fixes for
> > that one.  Can you share more details on this?  I think the failing
> > update is on table with oid=557732818, but I might be wrong.
> 
> That's exactly the table, public.schedulecard.
> We issue an UPDATE changing some of its columns. E.g.,
> 
> UPDATE public.schedulecard SET ext_ident=null,
> rotates=false,period_num=1,period_day=2 WHERE id=3817

What indexes are there in this table?  Indexes on expressions are
particularly suspect.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Disable recheck_on_update optimization to avoid crashes.

  2. Allow HOT updates for some expression indexes