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). -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
