Thread: pgsql: 9.3 release notes: move compatibility items into their own sect
9.3 release notes: move compatibility items into their own section Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/2497dc0867afd5b51d50e090fce2e828baadc8c3 Modified Files -------------- doc/src/sgml/release-9.3.sgml | 201 +++++++++++++++++++++-------------------- 1 files changed, 105 insertions(+), 96 deletions(-)
Re: pgsql: 9.3 release notes: move compatibility items into their own sect
From
Peter Geoghegan
Date:
On Fri, May 3, 2013 at 6:11 PM, Bruce Momjian <bruce@momjian.us> wrote: > 9.3 release notes: move compatibility items into their own section The commit_delay improvements should stay under performance, where I previously indicated they should be - it's clearly a notable new feature (commit_delay is way more effective now), as opposed to a tweak to the semantics of an existing feature. The fact that the behavior was changed could be separately noted, alongside the fact that Simon made commit_delay PGC_POSTMASTER (this is already separately noted anyway). Similarly, I think that this is a new feature that needs a separate compatibility note: Allow in-memory sorts to use their full memory allocation (Jeff Janes) It's possible that people were previously over-allocating memory to compensate for the server's former unwillingness to make full use of work_mem. You should specifically warn against that. -- Peter Geoghegan
On Fri, May 3, 2013 at 09:39:38PM -0700, Peter Geoghegan wrote: > On Fri, May 3, 2013 at 6:11 PM, Bruce Momjian <bruce@momjian.us> wrote: > > 9.3 release notes: move compatibility items into their own section > > The commit_delay improvements should stay under performance, where I > previously indicated they should be - it's clearly a notable new > feature (commit_delay is way more effective now), as opposed to a > tweak to the semantics of an existing feature. The fact that the > behavior was changed could be separately noted, alongside the fact > that Simon made commit_delay PGC_POSTMASTER (this is already > separately noted anyway). > > Similarly, I think that this is a new feature that needs a separate > compatibility note: > > Allow in-memory sorts to use their full memory allocation (Jeff Janes) > > It's possible that people were previously over-allocating memory to > compensate for the server's former unwillingness to make full use of > work_mem. You should specifically warn against that. OK, I moved commit_delay back to performance, and moved in-memory sorts up to compatibility. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +