From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Concurrently option for reindexdb |
Date: | 2014-08-26 03:44:43 |
Message-ID: | CAB7nPqT_PFdUKMNsynLL_3XY-yrprxGNnqfXB_wWHXiW7fOT=w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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...
> 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, 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 left notes on the wiki the status of this patch:
https://wiki.postgresql.org/wiki/Reindex_concurrently
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.
Regards,
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-08-26 03:46:13 | Re: SSL renegotiation |
Previous Message | Fujii Masao | 2014-08-26 03:28:28 | Re: Concurrently option for reindexdb |