OK, all changes made and committed. Thanks. (You can see the details
in the git commit.)
For this item:
* Correct predicate locking for DROP INDEX CONCURRENTLY -
bugfix not a feature
did you have new text. We do mention bug fixes. I changed "Correct" to
"Fix" in a later commit.
---------------------------------------------------------------------------
On Sun, Apr 21, 2013 at 08:57:08AM +0100, Simon Riggs wrote:
> On 21 April 2013 05:57, Bruce Momjian <bruce@momjian.us> wrote:
>
> > Reorder 9.3 release note items
>
> A few corrections, additions and clarifications.
>
> Corrections
>
> * Allow recovery.conf to be relocated using configuration variable
> recovery_config_directory
> Patch was revoked...
>
> * Need to mention the fast promote feature for standbys, which allows
> us to skip shutdown checkpoint, reducing failover time from minutes to
> seconds in busier databases
>
> * Correct predicate locking for DROP INDEX CONCURRENTLY - bugfix not a feature
>
> * Allow CREATE TABLE to succeed for a non-existent schema - should say
> CREATE TABLE IF NOT EXISTS in that para and the one below it
>
> * Previously functions already run in the current session ignored
> changes (what does that mean?? missing text)
>
> * Improve memory usage for in-memory sorts - IMHO this should read
> "Allow in-memory sorts to use their full memory allocation", which
> then explains why users may see higher memory usage and why they
> should think about altering settings
>
> Additions
>
> * I think it would be useful to say that pg_upgrade is now much faster
> because of the aggregate effect of the individual optimisations
> mentioned in the performance section.
>
> * "Require superuser privileges to set commit_delay"
> Meaning of commit_delay has changed and users should review their
> settings, if used
>
> * Add isolation tests for CREATE INDEX CONCURRENTLY - Abhijit Menon-Sen
>
>
> More info required...
>
> * Need to say why Pavan's work on VACUUM is related to performance
>
> * Need to say what effect Andres' patch to make HOT work on catalog
> tables will have
>
> * "Restructure WAL files to use a more compact storage format" - begs
> the question how much more compact?
>
> * Restructure WAL files to better handle timeline changes during
> recovery - need to explain "better"
>
> Thanks
>
> --
> Simon Riggs http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
