Re: Support for REINDEX CONCURRENTLY - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Support for REINDEX CONCURRENTLY
Date
Msg-id 50735ECE.6060101@nasby.net
Whole thread Raw
In response to Re: Support for REINDEX CONCURRENTLY  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Support for REINDEX CONCURRENTLY  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On 10/8/12 6:12 PM, Tom Lane wrote:
> Jim Nasby <jim@nasby.net> writes:
>> Yeah, what's the risk to renaming an index during concurrent access?
>
> SnapshotNow searches for the pg_class row could get broken by *any*
> transactional update of that row, whether it's for a change of relname
> or some other field.
>
> A lot of these problems would go away if we rejiggered the definition of
> SnapshotNow to be more like MVCC.  We have discussed that in the past,
> but IIRC it's not exactly a simple or risk-free change in itself.
> Still, maybe we should start thinking about doing that instead of trying
> to make REINDEX CONCURRENTLY safe given the existing infrastructure.

Yeah, I was just trying to remember what other situations this has come up in. My recollection is that there's been a
coupleother cases where that would be useful.
 

My recollection is also that such a change would be rather large... but it might be smaller than all the other
work-aroundsthat are needed because we don't have that...
 
-- 
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Support for REINDEX CONCURRENTLY
Next
From: Jim Nasby
Date:
Subject: Re: PQping command line tool