Date: Fri, 14 Nov 2014 16:02:08 +0100
From: Andres Freund <andres@2ndquadrant.com>
To: Jim Nasby <Jim.Nasby@BlueTreble.com>
Cc: Peter Eisentraut <peter_e@gmx.net>, Robert Haas <robertmhaas@gmail.com>,
 Michael Paquier <michael.paquier@gmail.com>, Jim Nasby <jim@nasby.net>,
 PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: REINDEX CONCURRENTLY 2.0
Message-ID: <20141114150208.GC11733@alap3.anarazel.de>
References: 
 <CAB7nPqSyZhdc-gvwm3KyueoceFJSX5ypQAx_rsJ2DWr5nHtixA@mail.gmail.com>
 <545B8AD2.8030203@gmx.net>
 <CA+TgmoZtd=sa8LD0tnWgRDzx-Zzt_g_FnPf9jtj61z_rbuse6w@mail.gmail.com>
 <CA+TgmoZ=0NMfMVjemYjO0zWFi8PS3OMZCEsqimcgc34U8UKQeg@mail.gmail.com>
 <20141112213912.GH13473@awork2.anarazel.de>
 <CA+TgmoZkJu-R58mBUVCJzFJvgeiQyJ2_1RfrZh6gy5LSzyCSag@mail.gmail.com>
 <20141113003106.GJ13473@awork2.anarazel.de>
 <5465215D.2060505@gmx.net>
 <61E955E2-61D7-45E8-BC66-F021EA0CE3CE@2ndquadrant.com>
 <5465B770.70604@BlueTreble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5465B770.70604@BlueTreble.com>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 2014-11-14 02:04:00 -0600, Jim Nasby wrote:
> On 11/13/14, 3:50 PM, Andres Freund wrote:
> Having been responsible for a site where downtime was a 6 figure
> dollar amount per hour, I've spent a LOT of time worrying about lock
> problems. The really big issue here isn't grabbing an exclusive lock;
> it's grabbing one at some random time when no one is there to actively
> monitor what's happening. (If you can't handle *any* exclusive locks,
> that also means you can never do an ALTER TABLE ADD COLUMN either.)

> With that in mind, would it be possible to set this up so that the
> time-consuming process of building the new index file happens first,
> and then (optionally) some sort of DBA action is required to actually
> do the relfilenode swap? I realize that's not the most elegant
> solution, but it's WAY better than this feature not hitting 9.5 and
> people having to hand-code a solution.

I don't think having a multi step version of the feature and it not
making into 9.5 are synonymous. And I really don't want to make it even
more complex before we have the basic version in.

I think a split like your:

> Possible syntax:
> REINDEX CONCURRENTLY -- Does what current patch does
> REINDEX CONCURRENT BUILD -- Builds new files
> REINDEX CONCURRENT SWAP -- Swaps new files in

could make sense, but it's really an additional feature ontop.

Greetings,

Andres Freund

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers