Horton
Menu

Re: Support for REINDEX CONCURRENTLY

Andres Freund <andres@2ndquadrant.com>

View thread
From: Andres Freund <andres@2ndquadrant.com>
To: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-hackers@postgresql.org
Date: 2013-06-17T20:00:05Z
Lists: pgsql-hackers 
On 2013-06-17 12:52:36 -0700, Josh Berkus wrote:
> 
> > Well, it can do lots stuff that DROP/CREATE CONCURRENTLY can't:
> > * reindex primary keys
> > * reindex keys referenced by foreign keys
> > * reindex exclusion constraints
> > * reindex toast tables
> > * do all that for a whole database
> > so I don't think that comparison is fair. Having it would have made
> > several previous point releases far less painful (e.g. 9.1.6/9.2.1).
> 
> FWIW, I have a client who needs this implementation enough that we're
> backporting it to 9.1 for them.

Wait. What? Unless you break catalog compatibility that's not safely
possible using this implementation.

Greetings,

Andres Freund

PS: Josh, minor thing, but could you please not trim the CC list, at
least when I am on it?

-- 
 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.