Re: DROP INDEX CONCURRENTLY is not really concurrency safe & leaves around undroppable indexes - Mailing list pgsql-hackers

From Andres Freund
Subject Re: DROP INDEX CONCURRENTLY is not really concurrency safe & leaves around undroppable indexes
Date
Msg-id 201209250146.18276.andres@2ndquadrant.com
Whole thread Raw
In response to DROP INDEX CONCURRENTLY is not really concurrency safe & leaves around undroppable indexes  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: DROP INDEX CONCURRENTLY is not really concurrency safe & leaves around undroppable indexes
List pgsql-hackers
Hi,

On Monday, September 24, 2012 01:27:54 PM Andres Freund wrote:
> Hi,
> 
> Problem 1: concurrency:
> 
> Testcase:
> 
> Session 1:
> CREATE TABLE test_drop_concurrently(id serial primary key, data int);
> INSERT INTO test_drop_concurrently(data) SELECT * FROM generate_series(1,
> 100000);
> CREATE INDEX test_drop_concurrently_data ON test_drop_concurrently(data);
> BEGIN;
> EXPLAIN ANALYZE SELECT * FROM test_drop_concurrently WHERE data = 34343;
> SELECT * FROM test_drop_concurrently WHERE data = 34343;
> (1 row)
> 
> Session 2:
> BEGIN;
> SELECT * FROM test_drop_concurrently WHERE data = 34343;
> 
> Session 3:
> DROP INDEX CONCURRENTLY test_drop_concurrently_data;
> (in-progress)
> 
> Session 2:
> INSERT INTO test_drop_concurrently(data) SELECT * FROM generate_series(1,
> 100000);
> COMMIT;
> 
> Session 1:
> SELECT * FROM test_drop_concurrently WHERE data = 34343;
> (1 row)
> SET enable_bitmapscan = false;
> SET enable_indexscan = false;
> SELECT * FROM test_drop_concurrently WHERE data = 34343;
> (2 rows)
> 
> Explanation:
> index_drop does:
>         indexForm->indisvalid = false;    /* make unusable for queries */
>         indexForm->indisready = false;    /* make invisible to changes */
> 
> Setting indisready = false is problematic because that prevents index
> updates which in turn breaks READ COMMITTED semantics. I think there need
> to be one more phase that waits for concurrent users of the index to
> finish before setting indisready = false.
The attached patch fixes this issue. Haven't looked at the other one in detail 
yet.

Greetings,

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

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_reorg in core?
Next
From: Brian Weaver
Date:
Subject: Patch: incorrect array offset in backend replication tar header