Skip site navigation (1) Skip section navigation (2)

Re: Support for REINDEX CONCURRENTLY

From: Greg Stark <stark(at)mit(dot)edu>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Re: Support for REINDEX CONCURRENTLY
Date: 2012-10-03 10:59:25
Message-ID: CAM-w4HNP1FCRojxbGJGQDQWeCCLjtRLPTjFa-g2HqocE+pz99g@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Just for background. The showstopper for REINDEX concurrently was not
that it was particularly hard to actually do the reindexing. But it's
not obvious how to obtain a lock on both the old and new index without
creating a deadlock risk. I don't remember exactly where the deadlock
risk lies but there are two indexes to lock and whichever order you
obtain the locks it might be possible for someone else to be waiting
to obtain them in the opposite order.

I'm sure it's possible to solve the problem. But the footwork needed
to release locks then reobtain them in the right order and verify that
the index hasn't changed out from under you might be a lot of
headache.

Perhaps a good way to tackle it is to have a generic "verify two
indexes are equivalent and swap the underlying relfilenodes" operation
that can be called from both regular reindex and reindex concurrently.
As long as it's the only function that ever locks two indexes then it
can just determine what locking discipline it wants to use.

-- 
greg


In response to

Responses

pgsql-hackers by date

Next:From: Andres FreundDate: 2012-10-03 11:08:24
Subject: Re: Support for REINDEX CONCURRENTLY
Previous:From: Boszormenyi ZoltanDate: 2012-10-03 09:41:40
Subject: Re: [PATCH] lock_timeout and common SIGALRM framework

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group