From: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Press Release Draft - 2016-02-09 Cumulative Update |
Date: | 2017-02-07 20:58:46 |
Message-ID: | E19D0C6D-AAE0-41F2-BD31-E4732047567A@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Feb 7, 2017, at 12:44 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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:
https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/20170209updaterelease.txt;h=f90d4716f240dbea4cca647b099f79865545b633;hb=d85498c284275bcab4752b91476834de780648b8 <https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/20170209updaterelease.txt;h=f90d4716f240dbea4cca647b099f79865545b633;hb=d85498c284275bcab4752b91476834de780648b8>
Thanks!
Jonathan
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-02-07 21:03:43 | Re: Parallel bitmap heap scan |
Previous Message | Jonathan S. Katz | 2017-02-07 20:56:48 | Re: Press Release Draft - 2016-02-09 Cumulative Update |