Re: Support for REINDEX CONCURRENTLY

Andres Freund <andres@2ndquadrant.com>

From: Andres Freund <andres@2ndquadrant.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>
Date: 2013-08-27T14:09:42Z
Lists: pgsql-hackers
On 2013-08-27 15:34:22 +0900, Michael Paquier wrote:
> I have been working a little bit more on this patch for the next
> commit fest. Compared to the previous version, I have removed the part
> of the code where process running REINDEX CONCURRENTLY was waiting for
> transactions holding a snapshot older than the snapshot xmin of
> process running REINDEX CONCURRENTLY at the validation and swap phase.
> At the validation phase, there was a risk that the newly-validated
> index might not contain deleted tuples before the snapshot used for
> validation was taken. I tried to break the code in this area by
> playing with multiple sessions but couldn't. Feel free to try the code
> and break it if you can!

Hm. Do you have any justifications for removing those waits besides "I
couldn't break it"? The logic for the concurrent indexing is pretty
intricate and we've got it wrong a couple of times without noticing bugs
for a long while, so I am really uncomfortable with statements like this.

Greetings,

Andres Freund

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


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Background worker processes

  2. Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.

  3. Work around unportable behavior of malloc(0) and realloc(NULL, 0).

  4. Properly set relpersistence for fake relcache entries.