First-draft release notes for next week's back-branch releases

On Friday, May 6, 2016, Tom Lane <tgl@sss.pgh.pa.us> wrote:

If you're not tired of reviewing release notes (I'm sure getting a bit
tired of writing them), see

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=eb7de00ac2d282263541ece849ec71e2809e9467

guaibasaurus should have 'em up on the web in an hour or so, too, at

http://www.postgresql.org/docs/devel/static/release-9-5-3.html

"...replacement_sort_tuples, which see for further details." needs
rewording.

For some reason I had trouble comprehending the index only scans on partial
index couple or paragraphs. Got it after a few reads. Seems like
it's almost too detailed.

"Partial indexes can be used for index only scans in some circumstances.
See section for details." If there isn't a section to point to there
should be - people want to know how to get IOS and aren't going to read
release notes to figure it out.

Are the pg_stat_activity changes breaking changes? If so its not clear
from the notes.

I'll +1 the elsewhere mentioned confusion adding a pg_config view vis-a-vis
pg_settings. Adding (or using) the word "compile" would be advisable.

The guc for the number of standby servers that must acknowledge should be
named in the notes and linked to the main docs. "An additional syntax has
been added to synchronous_standby_names to accommodate the number of
standby servers that must acknowledge a commit."

Is it worth mentioning the deprecation of exclusive backups in the notes
introducing non-exclusive ones?

Read the rest and nothing stood out - though I guess I'd advise myself or
the next person to read up from the bottom so fresh eyes read the lower
stuff first.

David J.

[ I think you meant to attach this to the other thread, but anyway... ]

"David G. Johnston" <david.g.johnston@gmail.com> writes:

"...replacement_sort_tuples, which see for further details." needs
rewording.

Hmm, "which see" is perfectly good English to my knowledge, and I'm not
sure that other possible ways of wording this would be less awkward.

Is it worth mentioning the deprecation of exclusive backups in the notes
introducing non-exclusive ones?

It's not clear to me that we're actually deprecating them; there did not
seem to be consensus on that.

I adopted your other suggestions. Thanks for reviewing!

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 09/05/16 08:56, Tom Lane wrote:

[ I think you meant to attach this to the other thread, but anyway... ]

"David G. Johnston" <david.g.johnston@gmail.com> writes:

"...replacement_sort_tuples, which see for further details." needs
rewording.

Hmm, "which see" is perfectly good English to my knowledge, and I'm not
sure that other possible ways of wording this would be less awkward.

[...]

To me the phrase "which see" is plain weird, at least in this context!
Is this some American usage I've not heard on TV nor films???

English is my first language, I was born in England and now reside in
New Zealand.

Cheers,
Gavin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Gavin Flower <GavinFlower@archidevsys.co.nz> writes:

On 09/05/16 08:56, Tom Lane wrote:

Hmm, "which see" is perfectly good English to my knowledge, and I'm not
sure that other possible ways of wording this would be less awkward.

To me the phrase "which see" is plain weird, at least in this context!
Is this some American usage I've not heard on TV nor films???

Don't think so. AFAIK it's a translation of the Latin "q.v." (quod vide),
and is used in more or less the same way. It's not hard to find examples
by googling.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 09/05/16 10:22, Tom Lane wrote:

Gavin Flower <GavinFlower@archidevsys.co.nz> writes:

On 09/05/16 08:56, Tom Lane wrote:

Hmm, "which see" is perfectly good English to my knowledge, and I'm not
sure that other possible ways of wording this would be less awkward.

To me the phrase "which see" is plain weird, at least in this context!
Is this some American usage I've not heard on TV nor films???

Don't think so. AFAIK it's a translation of the Latin "q.v." (quod vide),
and is used in more or less the same way. It's not hard to find examples
by googling.

regards, tom lane

Well I've come across many examples of examples of bad grammar, so
finding an example of usage in Google is not proof the usage is valid!

Even at best, it doesn't flow and is awkward.

Cheers,
Gavin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sunday, May 8, 2016, Tom Lane <tgl@sss.pgh.pa.us> wrote:

[ I think you meant to attach this to the other thread, but anyway... ]

This is where the link to the online version was; reading the sgml
and/or compiling ends up being a bit more than I wanted to do to review
these.

"David G. Johnston" <david.g.johnston@gmail.com <javascript:;>> writes:

"...replacement_sort_tuples, which see for further details." needs
rewording.

Hmm, "which see" is perfectly good English to my knowledge, and I'm not
sure that other possible ways of wording this would be less awkward.

Removing it doesn't seem like a bad choice...The user should realize the
relevant preceding linked guc is where they should look for more details -
pointing it out to them seems verbose. But the meaning is clear regardless
of familiarity.

Is it worth mentioning the deprecation of exclusive backups in the notes
introducing non-exclusive ones?

It's not clear to me that we're actually deprecating them; there did not
seem to be consensus on that.

Then section 24.3.3 needs fixing. The second paragraph explicitly states it
is deprecated.

http://www.postgresql.org/docs/devel/static/continuous-archiving.html

David J.