Re: Concurrently option for reindexdb

On 2014-08-26 12:44:43 +0900, Michael Paquier wrote:
> On Tue, Aug 26, 2014 at 12:28 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> >> +many. Although I'm not sure if we managed to find a safe relation swap.
>
> Well we didn't AFAIK. With the latest patch provided I could not
> really find any whole in the logic, and Andres felt that something may
> be wrong miles away. If I'd revisit the patch now with a rebased
> version maybe I may find smth...

I don't think it was miles away, but I'll look into the rebased version.

> > That safe relation swap is possible if an AccessExclusive lock is taken. Right?
> > That means that REINDEX CONCURRENTLY is not completely-concurrently, but
> > I think that many users are satisfied with even this feature.
>
> This would block as well isolation tests on this feature, something
> not that welcome for a feature calling itself concurrently,

Right. But it's much better than what we have now. Possibly we can
rename the feature... :/

> but it
> would deadly simplify the patch and reduce deadlock occurrences if
> done right with the exclusive locks (no need to check for past
> snapshots necessary when using ShareUpdateExclusiveLock?).

I'm not sure if you really can get rid of the waiting for past snapshots
without making the feature much more heavyweight htan necessary.

> Reading this thread, the consensus would be to use an exclusive lock
> for swap and be done. Well if there are enough votes for this approach
> I wouldn't mind resending an updated patch for the next CF.

I always was of the opinion that a exclusive lock is still *MUCH* better
than what we have today.

Greetings,

Andres Freund

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