Alpha 1 release notes

A Dimecres, 12 d'agost de 2009, Peter Eisentraut va escriure:

OK, since there was no clear consensus or volunteer for preparing release
notes for alpha 1, I have started something. Let me know what you think.

(reStructuredText, if you want to play around)

Maybe I'd be interesting to add development docs URL [1]http://developer.postgresql.org/pgdocs/postgres/index.html so testers can easily
find the syntax of new features, or given that they'll be downloading the
alpha tarball they should use that documentation?

[1]: http://developer.postgresql.org/pgdocs/postgres/index.html

--
Albert Cervera i Areny
http://www.NaN-tic.com
Mï¿œbil: +34 669 40 40 18

If I didn't read this email I would still be trying to figure out how
to use the explain XML patch. Thanks Albert.

I found the syntax for the explain xml format to be quite difficult to
understand at first, it would be nice to give an example or two, ie:

EXPLAIN (ANALYZE, FORMAT XML) SELECT * FROM foo WHERE i = 4;

The thing that caused me the most trouble was that the "," wasn't very
noticeable sitting near the end of this line:

EXPLAIN [ ( { ANALYZE boolean | VERBOSE boolean | COSTS boolean |
FORMAT { TEXT | XML | JSON } } [, ...] ) ] statement

It may just be me, but I read that as the comma being optional, not
mandatory in circumstances where you want to specify more then one
option.

Nonetheless, an additional example with multiple options would sure
help.

Thanks.

On Wed, 12 Aug 2009 01:08:54 +0200
Albert Cervera i Areny <albert@nan-tic.com> wrote:

A Dimecres, 12 d'agost de 2009, Peter Eisentraut va escriure:

OK, since there was no clear consensus or volunteer for preparing
release notes for alpha 1, I have started something. Let me know
what you think.

(reStructuredText, if you want to play around)

Maybe I'd be interesting to add development docs URL [1] so testers
can easily find the syntax of new features, or given that they'll be
downloading the alpha tarball they should use that documentation?

[1] http://developer.postgresql.org/pgdocs/postgres/index.html

--
Mike

Mike wrote:

The thing that caused me the most trouble was that the "," wasn't very
noticeable sitting near the end of this line:

EXPLAIN [ ( { ANALYZE boolean | VERBOSE boolean | COSTS boolean |
FORMAT { TEXT | XML | JSON } } [, ...] ) ] statement

It may just be me, but I read that as the comma being optional, not
mandatory in circumstances where you want to specify more then one
option.

It is you -- what's optional is having more than one option, but as soon
as you have a second one, the comma is mandatory.

I agree some examples would be useful.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On 8/11/09 3:27 PM, Peter Eisentraut wrote:

OK, since there was no clear consensus or volunteer for preparing release
notes for alpha 1, I have started something. Let me know what you think.

Actually, the "consensus" was that Bruce was not going to share, so
Robert and I didn't want to bother trying to compose formal release notes.

Can we put your text file somewhere we can collaborate on it? I started
a page on the wiki, but would gladly use your version as the seed instead:

http://wiki.postgresql.org/wiki/85AlphaFeatures

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On Tue, Aug 11, 2009 at 8:32 PM, Alvaro
Herrera<alvherre@commandprompt.com> wrote:

Mike wrote:

The thing that caused me the most trouble was that the "," wasn't very
noticeable sitting near the end of this line:

EXPLAIN [ ( { ANALYZE boolean | VERBOSE boolean | COSTS boolean |
FORMAT { TEXT | XML | JSON } } [, ...] ) ] statement

It may just be me, but I read that as the comma being optional, not
mandatory in circumstances where you want to specify more then one
option.

It is you -- what's optional is having more than one option, but as soon
as you have a second one, the comma is mandatory.

I agree some examples would be useful.

Hmm, I thought we had some examples in there, but now that I look we
only have an example for COSTS OFF, not for FORMAT. That does seem
like an oversight.

...Robert

Robert Haas <robertmhaas@gmail.com> writes:

Hmm, I thought we had some examples in there, but now that I look we
only have an example for COSTS OFF, not for FORMAT. That does seem
like an oversight.

I thought about adding one when I committed the patch, but concluded
that there was no point until the output format stabilized.

regards, tom lane

On Wednesday 12 August 2009 03:34:22 Josh Berkus wrote:

On 8/11/09 3:27 PM, Peter Eisentraut wrote:

OK, since there was no clear consensus or volunteer for preparing release
notes for alpha 1, I have started something. Let me know what you think.

Actually, the "consensus" was that Bruce was not going to share, so
Robert and I didn't want to bother trying to compose formal release notes.

Can we put your text file somewhere we can collaborate on it? I started
a page on the wiki, but would gladly use your version as the seed instead:

http://wiki.postgresql.org/wiki/85AlphaFeatures

Can you export DocBook from that?

Can you export DocBook from that?

Not without writing some custom perl code, no.

Should we stick your release notes on git somewhere? I'd like to expand
the and add a couple of things.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On Wednesday 12 August 2009 19:27:06 Josh Berkus wrote:

Can you export DocBook from that?

Not without writing some custom perl code, no.

Should we stick your release notes on git somewhere? I'd like to expand
the and add a couple of things.

I say just take the file and edit it.

On 8/12/09 11:13 AM, Peter Eisentraut wrote:

On Wednesday 12 August 2009 19:27:06 Josh Berkus wrote:

Can you export DocBook from that?

Not without writing some custom perl code, no.

Should we stick your release notes on git somewhere? I'd like to expand
the and add a couple of things.

I say just take the file and edit it.

Will do. Teaching myself RST now ....

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

Hi,

Josh Berkus <josh@agliodbs.com> writes:

Will do. Teaching myself RST now ....

I've been doing a lot of RST editing before, and found it pretty
straightforward. Except for default table handling, where ascii-art
maintenance is a pain, or you have to use extended tools, like emacs
table mode and such. Or use list-table and rejoy :)

http://docutils.sourceforge.net/docs/ref/rst/directives.html#list-table

Regards,
--
dim

within source code, build options there is:

- Reserve the shared memory region during backend startup on Windows,
so that memory allocated by starting third party DLLs doesn't end up
conflicting with it. Hopefully this solves the long-time issue with
"could not reattach to shared memory" errors on Win32.

I suggest that it should also be pointed out that this fix will be
backported to 8.3 and 8.4 (as much as I followed the ML); similiar to the
information at

- Fast shutdown stop should forcibly disconnect any active backends,
even if a smart shutdown is already in progress. Backpatched to 8.3.

best wishes

Harald

--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
LASIK good, steroids bad?

Dimitri Fontaine wrote:

Hi,

Josh Berkus <josh@agliodbs.com> writes:

Will do. Teaching myself RST now ....

I've been doing a lot of RST editing before, and found it pretty
straightforward. Except for default table handling, where ascii-art
maintenance is a pain, or you have to use extended tools, like emacs
table mode and such. Or use list-table and rejoy :)

http://docutils.sourceforge.net/docs/ref/rst/directives.html#list-table

Yeah, table handling in RST is pretty silly, particularly when you have
to escape some character in a cell.

I wonder if this format can be converted to SGML DocBook automatically.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On Thursday 13 August 2009 17:07:38 Alvaro Herrera wrote:

I wonder if this format can be converted to SGML DocBook automatically.

Yes, that's why I used it.

"Massa, Harald Armin" <chef@ghum.de> writes:

within source code, build options there is:
- Reserve the shared memory region during backend startup on Windows,
so that memory allocated by starting third party DLLs doesn't end up
conflicting with it. Hopefully this solves the long-time issue with
"could not reattach to shared memory" errors on Win32.

I suggest that it should also be pointed out that this fix will be
backported to 8.3 and 8.4 (as much as I followed the ML);

Normally, bug fixes that have been back-patched wouldn't be mentioned at
all in a new major release's release notes. The implied base that we
are comparing to in major-release notes is the end of the prior branch's
updates. I'm not sure if this case should be an exception, or if we
should have a different general rule for alpha releases. We'd like to
get more testing on that fix, so I think it is reasonable to mention it
for alpha1 --- but is that an exception specific to this bug fix, or
does it indicate we want to handle bug fixes differently in general
within alpha release notes?

In any case, it is not the function of the alpha release notes to
discuss changes in earlier release branches. The reason the commit
log points out the back-patch is to make it easier to extract the
information when we prepare release notes for the back-branch updates.

regards, tom lane

Tom Lane wrote:

In any case, it is not the function of the alpha release notes to
discuss changes in earlier release branches. The reason the commit
log points out the back-patch is to make it easier to extract the
information when we prepare release notes for the back-branch updates.

Hmm, isn't it enough to use cvs2cl --follow <branch>?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre@commandprompt.com> writes:

Tom Lane wrote:

In any case, it is not the function of the alpha release notes to
discuss changes in earlier release branches. The reason the commit
log points out the back-patch is to make it easier to extract the
information when we prepare release notes for the back-branch updates.

Hmm, isn't it enough to use cvs2cl --follow <branch>?

Yeah, cvs will certainly tell you the same information, which is why
I frequently don't bother mentioning the point at all in commit
messages. I think the most useful reason for mentioning the branch(es)
in a commit message is to explain why a particular patch goes back
so far and no farther.

regards, tom lane

Tom Lane wrote:

"Massa, Harald Armin" <chef@ghum.de> writes:

within source code, build options there is:
- Reserve the shared memory region during backend startup on Windows,
so that memory allocated by starting third party DLLs doesn't end up
conflicting with it. Hopefully this solves the long-time issue with
"could not reattach to shared memory" errors on Win32.

I suggest that it should also be pointed out that this fix will be
backported to 8.3 and 8.4 (as much as I followed the ML);

Normally, bug fixes that have been back-patched wouldn't be mentioned at
all in a new major release's release notes. The implied base that we
are comparing to in major-release notes is the end of the prior branch's
updates. I'm not sure if this case should be an exception, or if we
should have a different general rule for alpha releases. We'd like to
get more testing on that fix, so I think it is reasonable to mention it
for alpha1 --- but is that an exception specific to this bug fix, or
does it indicate we want to handle bug fixes differently in general
within alpha release notes?

In any case, it is not the function of the alpha release notes to
discuss changes in earlier release branches. The reason the commit
log points out the back-patch is to make it easier to extract the
information when we prepare release notes for the back-branch updates.

FYI, tools/pgcvslog -d removes backbranch commits automatically.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Peter,

Attached is a new draft of the "release notes".

What I've done in this version is added more subsections and arranged
stuff into groups by funcitonality area. I think this makes the notes
vastly easier to scan; having 25 items generically under "server" wasn't
helpful at all to find features and fixes.

I'd like to do 2 more things today:

a) rewrite a lot of the feature explanations more clearly so that most
of our users can understand (and test) them.

b) check against the gitlog to make sure we haven't missed anything.

What's my deadline?

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com