> On Feb 7, 2017, at 12:44 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
> Jonathan S. Katz wrote:
>> Below is the draft of the press release for the update this Thursday:
>> https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/20170209updaterelease.md;h=0cccb8986c08527f65f13d704a78c36bb8de7fef;hb=afc01091dea8a1597e8e21430edc3908c581ce0c
>> <https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/20170209updaterelease.md;h=0cccb8986c08527f65f13d704a78c36bb8de7fef;hb=afc01091dea8a1597e8e21430edc3908c581ce0c>
>> As there are a lot of updates I did my best to consolidate some of the 
>> bullet points and as usual, people are directed to the release notes.  
>> Please let me know if there are any inaccuracies so I can fix them ASAP.
> Please do post the proposed text on list for ease of review.  I wasn't
> looking at the text, so I wouldn't have noticed this if Emre hadn't
> replied:
>  76 If you believe you have been affected by the aforementioned CREATE INDEX 
> CONCURRENTLY bug, you will have to rebuild the index.  An example of 
> rebuilding an index:
>  77 
>  78     BEGIN;
>  79     DROP INDEX bad_index_name;
>  80     CREATE INDEX CONCURRENTLY bad_index_name ON table_name (column_name); 
> /* replace names with your original index definition */
>  81     COMMIT;
> This is not a good recipe, because using CREATE INDEX CONCURRENTLY in
> the same transaction that grabs an exclusive lock on the table for the
> DROP INDEX is pointless -- the access exclusive lock is held until the
> end of the transaction, and CIC does not work inside a transaction
> anyway so it'd raise an ERROR and rollback the DROP INDEX.  So the user
> would probably drop the BEGIN/COMMIT sequence in order for this to work
> in the first place.  (The other option is to use CREATE INDEX not
> concurrent, but that would lock the table for a very long time).

Thanks for the clarification.  I have updated the recipe along with Emre’s 
comments here:




Reply via email to