Re: uninterruptable loop: concurrent delete in progress within table - Mailing list pgsql-bugs

From Andres Freund
Subject Re: uninterruptable loop: concurrent delete in progress within table
Date
Msg-id 20140531132841.GC1220@awork2.anarazel.de
Whole thread Raw
In response to uninterruptable loop: concurrent delete in progress within table  (Sandro Santilli <strk@keybit.net>)
Responses Re: uninterruptable loop: concurrent delete in progress within table  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: uninterruptable loop: concurrent delete in progress within table  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-bugs
Hi,

On 2014-05-30 16:31:50 +0200, Sandro Santilli wrote:
> The attached script shows a plpgsql function that enters
> an infinite loop which is not interrupted by statement_timeout.

>  WARNING:  concurrent delete in progress within table "crash9", xid is 4458893, self is 4458894/4458889
>  CONTEXT:  SQL statement "CREATE INDEX ON crash9 USING GIST ( the_geom)"
>  PL/pgSQL function crash(regclass) line 148 at EXECUTE statement

I've attached a patch including an explanatory commit message. It
includes a regression test that fails with an endless loop on all
supported releases before the fix is applied.

Tom, Alvaro, All: Since it needs to fix HeapTupleSatisfiesVacuum() and
those routines are tricky I'd very much welcome a look over the
changes. As e.g. evidenced that exactly the buggy lines have been
whacked around repeatedly a long time ago.
Especially the slight behavioural change of HTSV deserves some review.

I do wonder if any of the other existing callers of HTSV are affected. I
don't understand predicate.c well enough to be sure, but it looks to me
like it'd could in theory lead to missed conflicts. Seems fairly
unlikely to matter in practice though.

I have to say I really hate the amount of repetitive code inside the
individual visibility routines. Obviously it's nothing backpatchable and
may become moot to a certain degree with the CSN work, but those are
pretty close to being unmaintainable.

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-bugs by date:

Previous
From: Noah Misch
Date:
Subject: Re: BUG #10347: Can't write password to psql or pg_dump
Next
From: Tom Lane
Date:
Subject: Re: postgresql test failure with Python 3.4.0 in plpython_do