pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Andres Freund <andres@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Jim Nasby <jim@nasby.net>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: REINDEX CONCURRENTLY 2.0
Date: Mon, 2 Feb 2015 15:10:14 +0100
Message-ID: <20150202141014.GA9201@alap3.anarazel.de> (raw)
In-Reply-To: <CA+TgmoZ=0NMfMVjemYjO0zWFi8PS3OMZCEsqimcgc34U8UKQeg@mail.gmail.com>
References: <CAB7nPqSTFkuc7dZxCDX4HOTU63YXHRroNv2aoUzyD-Zz_8Z_Zg@mail.gmail.com>
	<52CF45E8.6090208@nasby.net>
	<CAB7nPqTZfx20Ra2Wf4Gm0a=NqF4q2aC8Q6OS8vKN6fhnD=cUxQ@mail.gmail.com>
	<CAB7nPqRkwKFgn4BFUybqU-Oo-=Gcbq0K-8H93Gr6fX-GGRPDXg@mail.gmail.com>
	<20140827064120.GZ21544@awork2.anarazel.de>
	<CAB7nPqSdSMeQMCvtt9P+ndfao5ALpVPDEMmaBPVjNiifLzb=3Q@mail.gmail.com>
	<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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

On 2014-11-12 16:11:58 -0500, Robert Haas wrote:
> On Wed, Nov 12, 2014 at 4:10 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> > On Thu, Nov 6, 2014 at 9:50 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> >> If REINDEX cannot work without an exclusive lock, we should invent some
> >> other qualifier, like WITH FEWER LOCKS.
> >
> > What he said.
> 
> But more to the point .... why, precisely, can't this work without an
> AccessExclusiveLock?  And can't we fix that instead of setting for
> something clearly inferior?

So, here's an alternative approach of how to get rid of the AEL
locks. They're required because we want to switch the relfilenodes
around. I've pretty much no confidence in any of the schemes anybody has
come up to avoid that.

So, let's not switch relfilenodes around.

I think if we should instead just use the new index, repoint the
dependencies onto the new oid, and then afterwards, when dropping,
rename the new index one onto the old one. That means the oid of the
index will change and some less than pretty grovelling around
dependencies, but it still seems preferrable to what we're discussing
here otherwise.

Does anybody see a fundamental problem with that approach?

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



view thread (170+ messages)  latest in thread

Message-ID: <20150202141014.GA9201@alap3.anarazel.de>
Permalink:  ../20150202141014.GA9201@alap3.anarazel.de/
Also on:    postgresql.org/message-id/20150202141014.GA9201@alap3.anarazel.de

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: andres@2ndquadrant.com, robertmhaas@gmail.com, peter_e@gmx.net, michael.paquier@gmail.com, jim@nasby.net
  Subject: Re: REINDEX CONCURRENTLY 2.0
  In-Reply-To: <20150202141014.GA9201@alap3.anarazel.de>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox