9.4 release notes

I have completed the initial version of the 9.4 release notes. You can
view them here:

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

I will be adding additional markup in the next few days.

Feedback expected and welcomed. I expect to be modifying this until we
release 9.4 final. I have marked items where I need help with question
marks.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

Hi,

On 2014-05-04 08:46:07 -0400, Bruce Momjian wrote:
> Feedback expected and welcomed. I expect to be modifying this until we
> release 9.4 final. I have marked items where I need help with question
> marks.

Thanks for doing that work. Some comments inline:

+ <listitem>
+ <para>
+ Remove system column pg_class.reltoastidxid (Michael Paquier)
+ </para>
+
+ <para>
+ Instead use normal index access methods.
+ </para>
+ </listitem>

The explanation doesn't seem helpful to me. I'd just remove it as the
full explanation seems to be to complex and not actually interesting.

+ <sect3>
+ <title>Server</title>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Have VACUUM properly report dead but not removable rows to the statistics collector (Hari Babu)
+ </para>
+
+ <para>
+ Previously these were reported as live rows.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Improve SSL renegotiation handling (&Aacute;lvaro Herrera)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ During immediate shutdown, send uncatchable termination signals to child processes that have not already shutdown (MauMau,
+ &Aacute;lvaro Herrera)
+ </para>
+
+ <para>
+ This reduces the likelihood of orphaned child processes after postmaster shutdown.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Improve randomness of the database system identifier (Tom Lane)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Allow background workers to be dynamically started and terminated (Robert Haas)
+ </para>

This is much more important than the previous features imo. Also, I'd
add the word "registered" in the above list.

+ <listitem>
+ <para>
+ Allow dynamic allocation of shared memory segments (Robert Haas, Amit Kapila)
+ </para>
+ </listitem>

Should also be earlier in the list.

+ <listitem>
+ <para>
+ Freeze tuples when tables are written with CLUSTER or VACUUM FULL (Robert Haas, Andres Freund)
+ </para>
+
+ <para>
+ This avoids later freezing overhead.
+ </para>
+ </listitem>

This sentence seems a bit awkward to me. Maybe "This avoids the need to
freeze tuples at some later point in time."

+ <listitem>
+ <para>
+ Improve speed of accessing many sequence values (David Rowley)
+ </para>
+ </listitem>

I think this description isn't accurate. Isn't it something like
"Improve speed of accesessing many different sequences in the same backend."

+ <listitem>
+ <para>
+ Use memory barriers to avoid some spinlock use (Heikki Linnakangas)
+ </para>
+ </listitem>

This is about 1a3d104475ce01326fc00601ed66ac4d658e37e5? If so I'd put it
as: "Reduce spinlock contention during WAL replay." or similar.

This imo deserves to be further up this list as this is one of the
biggest bottlenecks in HS node performance.

+ <listitem>
+ <para>
+ Add huge_pages configuration parameter to attempt to use huge translation look-aside buffer (TLB) pages on Linux (Christian Kruse,
+ Richard Poole, Abhijit Menon-Sen)
+ </para>

I think this is too detailed - how about: "... to use huge pages ..."?

+ <para>
+ This can improve performance on large memory systems.
+ </para>
+ </listitem>

Should this be in the performance section?

+ <listitem>
+ <para>
+ Add configuration variable data_checksums to report whether data page checksums are enabled (Bernd Helmle)
+ </para>
+ </listitem>

Since this has been backpatched since it should probably be removed.

+ <listitem>
+ <para>
+ Use the last specified recovery_target if multiple are specified (Heikki Linnakangas)
+ </para>
+ </listitem>

This might want an entry in the compatibility section.

+ <listitem>
+ <para>
+ Add replication slots to report the WAL activity on streaming standbys (Andres Freund, Robert Haas)
+ </para>
+
+ <para>
+ Description? Logical only?
+ </para>
+ </listitem>

No, it's not logical only. How about:
'Replication slots allow to reserve resources like WAL on the primary
that are needed by standby servers."

+ <listitem>
+ <para>
+ Improve return codes from external recovery commands (Peter Eisentraut)
+ </para>
+ </listitem>

This doesn't seem to be very descriptive. s/improve/report/?

+ <listitem>
+ <para>
+ Write WAL records of running transactions every 15 seconds ? (Andres Freund)
+ </para>
+ </listitem>

"Write WAL records about running transactions more frequently."

"This allows standby servers to startup faster and to cleanup resources
more aggressively."

+ </itemizedlist>
+
+ <sect4>
+ <title>Logical Change-Set Encoding</title>

s/Encoding/Extraction/

This probably deserves one entry about the new feature instead of
separate entries about individually commited parts.

REPLICA IDENTITY should probably documented separately. Other solutions
can use it as well.

+ <listitem>
+ <para>
+ Allow security barrier views automatically updateable (Dean Rasheed)
+ </para>

*to be?

+ <listitem>
+ <para>
+ Add functions pg_filenode_relation() and pg_relation_filepath() to do relation/relfilenode conversions (Andres Freund)
+ </para>

pg_relation_filepath() isn't new. I think this should be something like:
"Add function pg_filenode_relation() to allow for more efficient
filenode to relation lookup."

+ <para>
+ These use a new pg_class index to speed lookups.
+ </para>
+ </listitem>

Don't think that's interesting for the release notes.

+ <listitem>
+ <para>
+ Have \d display disabled system triggers (Bruce Momjian)
+ </para>
+
+ <para>
+ Previously if you disabled all triggers, only user triggers would show as disabled.
+ </para>
+ </listitem>

Maybe mention that this could lead to broken foreign key checks after an
ALTER TABLE .. DISABLE TRIGGERS?.

+ <sect3>
+ <title>Source Code</title>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Improve the way tuples are frozen, to preserve forensic information ((Robert Haas, Andres Freund)
+ </para>
+
+ <para>
+ Code that inspects tuple flag bits will need to be modified
+ </para>
+ </listitem>

Not sure if that's just a source code level change.

+ <listitem>
+ <para>
+ Remove SnapshotNow and HeapTupleSatisfiesNow (Robert Haas)
+ </para>
+
+ <para>
+ All existing uses have been switched to more appropriate snapshot types.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Use an MVCC snapshot (rather than SnapshotNow) for catalog scans (Robert Haas)
+ </para>
+ </listitem>

I wonder if those two shouldn't be one entry.

+ <listitem>
+ <para>
+ Use printf() modifier "z" to specify size_t values (Andres Freund)
+ </para>
+ </listitem>

s/Use/Add infrastructure to allow to use the %x printf modifier .../

+ <listitem>
+ <para>
+ Memory barrier changes?
+ </para>
+ </listitem>

Not sure what that refers to?

+ <listitem>
+ <para>
+ Remove spinlock support for unsupported platforms SINIX, Sun3, and NS32K (Robert Haas)
+ </para>
+ </listitem>

I'd put it as "Remove leftover code for the unsupported
... platforms.".

+ <listitem>
+ <para>
+ Rewrite duplicate_oids Unix hell script in Perl (Andrew Dunstan)
+ </para>
+ </listitem>

Heh. s/hell/shell/

+ <listitem>
+ <para>
+ Remove IRIX port (Robert Haas)
+ </para>
+ </listitem>

Should probably be next to the unsupported platforms list.

+ <listitem>
+ <para>
+ Have pg_stat_statements use a flat file for query text storage, allowing higher limits (Peter Geoghegan)
+ </para>
+
+ <para>
+ Also add the ability to retrieve all pg_stat_statements information except the query text. This allows programs to reuse the query
+ text already retrieved by referencing queryid.
+ </para>
+ </listitem>

This isn't an optional thing, is it?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Bruce,

you forgot Alexander Korotkov, who contributed jsonb_hash_ops opclass
for GIN. Something like
"Alexander Korotkov introduced an elegant jsonb_hash ops for GIN,
which competes with MongoDB performance in contains operator".

Here is a link to discussion -
http://www.postgresql.org/message-id/53304439.8000602@dunslane.net

Oleg

On Sun, May 4, 2014 at 4:46 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> I have completed the initial version of the 9.4 release notes. You can
> view them here:
>
> http://www.postgresql.org/docs/devel/static/release-9-4.html
>
> I will be adding additional markup in the next few days.
>
> Feedback expected and welcomed. I expect to be modifying this until we
> release 9.4 final. I have marked items where I need help with question
> marks.
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + Everyone has their own god. +
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

On 04/05/14 14:46, Bruce Momjian wrote:
> I have completed the initial version of the 9.4 release notes. You can
> view them here:
>
> http://www.postgresql.org/docs/devel/static/release-9-4.html
>
> I will be adding additional markup in the next few days.
>
> Feedback expected and welcomed. I expect to be modifying this until we
> release 9.4 final. I have marked items where I need help with question
> marks.
>

Nice work,

one comment from me would be about jsonb:

+ <listitem>
+ <para>
+ Add structured (non-text) data type (jsonb) for storing JSON
data (Oleg Bartunov, Teodor Sigaev, Peter Geoghegan and Andrew Dunstan)
+ </para>
+
+ <para>
+ This data type allows faster indexing and access to json
keys/value pairs.
+ </para>
+ </listitem>

I think the explanation should be expanded to say that this data type
also has generic indexing not just faster indexing.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On 05/04/2014 10:12 AM, Petr Jelinek wrote:
> On 04/05/14 14:46, Bruce Momjian wrote:
>> I have completed the initial version of the 9.4 release notes. You can
>> view them here:
>>
>> http://www.postgresql.org/docs/devel/static/release-9-4.html
>>
>> I will be adding additional markup in the next few days.
>>
>> Feedback expected and welcomed. I expect to be modifying this until we
>> release 9.4 final. I have marked items where I need help with question
>> marks.
>>
>
> Nice work,
>
> one comment from me would be about jsonb:
>
> + <listitem>
> + <para>
> + Add structured (non-text) data type (jsonb) for storing JSON
> data (Oleg Bartunov, Teodor Sigaev, Peter Geoghegan and Andrew Dunstan)
> + </para>
> +
> + <para>
> + This data type allows faster indexing and access to json
> keys/value pairs.
> + </para>
> + </listitem>
>
> I think the explanation should be expanded to say that this data type
> also has generic indexing not just faster indexing.
>

It's also slightly ambiguous - it's not immediately clear that the
"faster" also applies to the "access".

cheers

andrew

On Sun, May 4, 2014 at 4:06 PM, Oleg Bartunov <obartunov(at)gmail(dot)com> wrote:

> Bruce,
>
> you forgot Alexander Korotkov, who contributed jsonb_hash_ops opclass
> for GIN. Something like
> "Alexander Korotkov introduced an elegant jsonb_hash ops for GIN,
> which competes with MongoDB performance in contains operator".
>
> Here is a link to discussion -
> http://www.postgresql.org/message-id/53304439.8000602@dunslane.net

Aexanders work should definitely be credited in the release notes, but
please let's not mention MongoDB (or any other product for that matter) in
the release notes - they are about the technology, not the advocacy.
(That's for things like the press kit..)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

I agree, no mongo :)

On Sun, May 4, 2014 at 8:47 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>
> On Sun, May 4, 2014 at 4:06 PM, Oleg Bartunov <obartunov(at)gmail(dot)com> wrote:
>>
>> Bruce,
>>
>> you forgot Alexander Korotkov, who contributed jsonb_hash_ops opclass
>> for GIN. Something like
>> "Alexander Korotkov introduced an elegant jsonb_hash ops for GIN,
>> which competes with MongoDB performance in contains operator".
>>
>> Here is a link to discussion -
>> http://www.postgresql.org/message-id/53304439.8000602@dunslane.net
>
>
> Aexanders work should definitely be credited in the release notes, but
> please let's not mention MongoDB (or any other product for that matter) in
> the release notes - they are about the technology, not the advocacy. (That's
> for things like the press kit..)
>
> --
> Magnus Hagander
> Me: http://www.hagander.net/
> Work: http://www.redpill-linpro.com/

On 05/04/2014 03:46 PM, Bruce Momjian wrote:
> I have completed the initial version of the 9.4 release notes.

Thanks!

> You can view them here:
>
> http://www.postgresql.org/docs/devel/static/release-9-4.html
>
> I will be adding additional markup in the next few days.
>
> Feedback expected and welcomed. I expect to be modifying this until we
> release 9.4 final. I have marked items where I need help with question
> marks.

Two rather large changes to the B-tree algorithms are missing:

* Fix race condition in B-tree page deletion (commit efada2b8)

* Make the handling of interrupted B-tree page splits more robust
(commit 40dae7ec)

These changes are not visible to users, but they are good toknow for
beta testers.

- Heikki

On 05/04/2014 03:46 PM, Bruce Momjian wrote:
> Auto-resize the catalog cache (Heikki Linnakangas)
>
> This reduces memory consumption for backends accessing only a few
> tables, and improves performance for backend accessing many tables.

Move this to "General performance" section.

> Improve spinlock speed on x86_64 CPUs (test on i386?) (Heikki Linnakangas)

I believe this refers to commit b03d196b. The "test on i386" note can
just be removed. Someone ought to test it on 32-bit i386 to see if the
same change would be beneficial there, but that's a TODO item more than
a release notes item. I doubt anyone's interested to spend time
performance testing spinlocks on 32-bit i386, though, so I think we're
going to just retain the current situation for the next decade.

- Heikki

On Sun, May 4, 2014 at 03:49:27PM +0200, Andres Freund wrote:
> Hi,
>
> On 2014-05-04 08:46:07 -0400, Bruce Momjian wrote:
> > Feedback expected and welcomed. I expect to be modifying this until we
> > release 9.4 final. I have marked items where I need help with question
> > marks.
>
> Thanks for doing that work. Some comments inline:

Oh, I forgot to thank committers for making this job easier every year.
The commit titles are helpful, the descriptions good, and many items are
marked as backward incompatible where appropriate. Git hashes make
looking up commit details easy.

> + <listitem>
> + <para>
> + Remove system column pg_class.reltoastidxid (Michael Paquier)
> + </para>
> +
> + <para>
> + Instead use normal index access methods.
> + </para>
> + </listitem>
>
> The explanation doesn't seem helpful to me. I'd just remove it as the
> full explanation seems to be to complex and not actually interesting.

OK, description removed. I know pg_upgrade has to be modified to handle
this. Hopefully others will understand how to adjust things. You are
right that the full description is complex.

>
> + <sect3>
> + <title>Server</title>
> +
> + <itemizedlist>
> +
> + <listitem>
> + <para>
> + Have VACUUM properly report dead but not removable rows to the statistics collector (Hari Babu)
> + </para>
> +
> + <para>
> + Previously these were reported as live rows.
> + </para>
> + </listitem>
> +
> + <listitem>
> + <para>
> + Improve SSL renegotiation handling (&Aacute;lvaro Herrera)
> + </para>
> + </listitem>
> +
> + <listitem>
> + <para>
> + During immediate shutdown, send uncatchable termination signals to child processes that have not already shutdown (MauMau,
> + &Aacute;lvaro Herrera)
> + </para>
> +
> + <para>
> + This reduces the likelihood of orphaned child processes after postmaster shutdown.
> + </para>
> + </listitem>
> +
> + <listitem>
> + <para>
> + Improve randomness of the database system identifier (Tom Lane)
> + </para>
> + </listitem>
> +
> + <listitem>
> + <para>
> + Allow background workers to be dynamically started and terminated (Robert Haas)
> + </para>
>
> This is much more important than the previous features imo. Also, I'd
> add the word "registered" in the above list.
>
> + <listitem>
> + <para>
> + Allow dynamic allocation of shared memory segments (Robert Haas, Amit Kapila)
> + </para>
> + </listitem>
>
> Should also be earlier in the list.

OK, added "registered" and I moved this item and the one above to #2 and
#3. Let me know if that isn't good. I was thinking the dynamic stuff
wasn't useful until we had parallelism working, but I think I was wrong.

>
> + <listitem>
> + <para>
> + Freeze tuples when tables are written with CLUSTER or VACUUM FULL (Robert Haas, Andres Freund)
> + </para>
> +
> + <para>
> + This avoids later freezing overhead.
> + </para>
> + </listitem>
>
> This sentence seems a bit awkward to me. Maybe "This avoids the need to
> freeze tuples at some later point in time."

OK, I wrote, "This avoids the need to freeze the tuples in the future."
>
> + <listitem>
> + <para>
> + Improve speed of accessing many sequence values (David Rowley)
> + </para>
> + </listitem>
>
> I think this description isn't accurate. Isn't it something like
> "Improve speed of accesessing many different sequences in the same backend."

Yes, better, thanks.

> + <listitem>
> + <para>
> + Use memory barriers to avoid some spinlock use (Heikki Linnakangas)
> + </para>
> + </listitem>
>
> This is about 1a3d104475ce01326fc00601ed66ac4d658e37e5? If so I'd put it
> as: "Reduce spinlock contention during WAL replay." or similar.

Uh, yes. I am not sure why I fixed on the memory barrier/spinlock part.
I used your text and moved it to the replication section.

> This imo deserves to be further up this list as this is one of the
> biggest bottlenecks in HS node performance.

I didn't move it too high up as it isn't a user-visible change, but I
put it at the top of the non-visible part. Let me know if it needs
further promotion.

> + <listitem>
> + <para>
> + Add huge_pages configuration parameter to attempt to use huge translation look-aside buffer (TLB) pages on Linux (Christian Kruse,
> + Richard Poole, Abhijit Menon-Sen)
> + </para>
>
> I think this is too detailed - how about: "... to use huge pages ..."?

I am not sure on this as the default is "try", but I updated the wording
like your suggested:

Add huge_pages configuration parameter to enable huge
translation look-aside buffer (TLB) pages on Linux

> + <para>
> + This can improve performance on large memory systems.
> + </para>
> + </listitem>
>
> Should this be in the performance section?

Well, performance is listed as "General Performance". We also have index
changes that help performance too but they are under "Index". I think
it is probably in the right place as "configuration" is more specific
than "general performance".

> + <listitem>
> + <para>
> + Add configuration variable data_checksums to report whether data page checksums are enabled (Bernd Helmle)
> + </para>
> + </listitem>
>
> Since this has been backpatched since it should probably be removed.

Oh, I missed that. Removed. When commits are _later_ backpatched, I
sometimes miss that.

>
> + <listitem>
> + <para>
> + Use the last specified recovery_target if multiple are specified (Heikki Linnakangas)
> + </para>
> + </listitem>
>
> This might want an entry in the compatibility section.

Hmmm, good question. I always assumed doing multiple recovery_targets
was just user error, but I can see people who relied on that. Moved.

>
> + <listitem>
> + <para>
> + Add replication slots to report the WAL activity on streaming standbys (Andres Freund, Robert Haas)
> + </para>
> +
> + <para>
> + Description? Logical only?
> + </para>
> + </listitem>
>
> No, it's not logical only. How about:
> 'Replication slots allow to reserve resources like WAL on the primary
> that are needed by standby servers."

OK, new wording:

Replication slots allow preservation of resources like WAL files on the
primary that are needed by standby servers.

>
> + <listitem>
> + <para>
> + Improve return codes from external recovery commands (Peter Eisentraut)
> + </para>
> + </listitem>
>
> This doesn't seem to be very descriptive. s/improve/report/?

Oh, I missed that nuance. Updated.

> + <listitem>
> + <para>
> + Write WAL records of running transactions every 15 seconds ? (Andres Freund)
> + </para>
> + </listitem>
>
> "Write WAL records about running transactions more frequently."
>
> "This allows standby servers to startup faster and to cleanup resources
> more aggressively."

Yes, that is exactly what I needed to know! I couldn't figure that out.
Added.

> + </itemizedlist>
> +
> + <sect4>
> + <title>Logical Change-Set Encoding</title>
>
> s/Encoding/Extraction/
>
> This probably deserves one entry about the new feature instead of
> separate entries about individually commited parts.

I added a paragraph at the top to explain the feature. We added a bunch
of new stuff as far as user-visible changes so I kept them listed,
particularly because it isn't clear right away that they are related to
this feature.

> REPLICA IDENTITY should probably documented separately. Other solutions
> can use it as well.

Well, as far as 9.4 it is for this feature, so putting it somewhere else
doesn't make sense to me. If someone else uses it in a future release
we can document that too.

>
> + <listitem>
> + <para>
> + Allow security barrier views automatically updateable (Dean Rasheed)
> + </para>
>
> *to be?

Fixed.

>
> + <listitem>
> + <para>
> + Add functions pg_filenode_relation() and pg_relation_filepath() to do relation/relfilenode conversions (Andres Freund)
> + </para>
>
> pg_relation_filepath() isn't new. I think this should be something like:
> "Add function pg_filenode_relation() to allow for more efficient
> filenode to relation lookup."

Done.

>
> + <para>
> + These use a new pg_class index to speed lookups.
> + </para>
> + </listitem>
>
> Don't think that's interesting for the release notes.

OK, removed. Your text got the performance aspect.
>
> + <listitem>
> + <para>
> + Have \d display disabled system triggers (Bruce Momjian)
> + </para>
> +
> + <para>
> + Previously if you disabled all triggers, only user triggers would show as disabled.
> + </para>
> + </listitem>
>
> Maybe mention that this could lead to broken foreign key checks after an
> ALTER TABLE .. DISABLE TRIGGERS?.

That seems too complex for the release notes. The new display was to
remind people that they had system-level triggers disabled. I don't think we
want to get into telling people _why_ they need to be reminded.

> + <sect3>
> + <title>Source Code</title>
> +
> + <itemizedlist>
> +
> + <listitem>
> + <para>
> + Improve the way tuples are frozen, to preserve forensic information ((Robert Haas, Andres Freund)
> + </para>
> +
> + <para>
> + Code that inspects tuple flag bits will need to be modified
> + </para>
> + </listitem>
>
> Not sure if that's just a source code level change.

I am unclear as well, but I assume people viewing rows via pgstattuple
would need to adjust things.

> + <listitem>
> + <para>
> + Remove SnapshotNow and HeapTupleSatisfiesNow (Robert Haas)
> + </para>
> +
> + <para>
> + All existing uses have been switched to more appropriate snapshot types.
> + </para>
> + </listitem>
> +
> + <listitem>
> + <para>
> + Use an MVCC snapshot (rather than SnapshotNow) for catalog scans (Robert Haas)
> + </para>
> + </listitem>
>
> I wonder if those two shouldn't be one entry.

Agreed. Put the "catalog scans" item in the description of the previous
item.
>
> + <listitem>
> + <para>
> + Use printf() modifier "z" to specify size_t values (Andres Freund)
> + </para>
> + </listitem>
>
> s/Use/Add infrastructure to allow to use the %x printf modifier .../

Done.

>
> + <listitem>
> + <para>
> + Memory barrier changes?
> + </para>
> + </listitem>
>
> Not sure what that refers to?

I think it is this. I have no idea if it is important:

Fix a few problems in barrier.h.

On HPPA, implement pg_memory_barrier() as pg_compiler_barrier(), which
should be correct since this arch doesn't do memory access reordering,
and is anyway better than the completely-nonfunctional-on-this-arch
dummy_spinlock code. (But note this patch only fixes things for gcc,
not for builds with HP's compiler.)

Also, fix incorrect default definition of pg_memory_barrier as a macro
requiring an argument.

Also, fix incorrect spelling of "#elif" as "#else if" in icc code path
(spotted by pgindent).

This doesn't come close to fixing all of the functional and stylistic
deficiencies in barrier.h, but at least it un-breaks my personal build.
Now that we're actually using barriers in the code, this file is going
to need some serious attention.

(Tom Lane)
[89779bf2c] 2013-07-17 18:38:20 -0400

I have removed the release note item on it.

> + <listitem>
> + <para>
> + Remove spinlock support for unsupported platforms SINIX, Sun3, and NS32K (Robert Haas)
> + </para>
> + </listitem>
>
> I'd put it as "Remove leftover code for the unsupported
> ... platforms.".

I think I worded it that way because we really _just_ remove the
spinlock stuff --- the rest of the support was gone long ago, I think.
In fact, I think they are CPU types, not actual platforms, at least for
NS32K.

> + <listitem>
> + <para>
> + Rewrite duplicate_oids Unix hell script in Perl (Andrew Dunstan)
> + </para>
> + </listitem>
>
> Heh. s/hell/shell/

Yes, funny, and removed. ;-)

> + <listitem>
> + <para>
> + Remove IRIX port (Robert Haas)
> + </para>
> + </listitem>
>
> Should probably be next to the unsupported platforms list.

Agreed. Removed.

> + <listitem>
> + <para>
> + Have pg_stat_statements use a flat file for query text storage, allowing higher limits (Peter Geoghegan)
> + </para>
> +
> + <para>
> + Also add the ability to retrieve all pg_stat_statements information except the query text. This allows programs to reuse the query
> + text already retrieved by referencing queryid.
> + </para>
> + </listitem>
>
> This isn't an optional thing, is it?

Here is the commit:

Keep pg_stat_statements' query texts in a file, not in shared memory.

This change allows us to eliminate the previous limit on stored query
length, and it makes the shared-memory hash table very much smaller,
allowing more statements to be tracked. (The default value of
pg_stat_statements.max is therefore increased from 1000 to 5000.)
In typical scenarios, the hash table can be large enough to hold all the
statements commonly issued by an application, so that there is little
"churn" in the set of tracked statements, and thus little need to do I/O
to the file.

--> To further reduce the need for I/O to the query-texts file, add a way
--> to retrieve all the columns of the pg_stat_statements view except for
the query text column. This is probably not of much interest for human
use but it could be exploited by programs, which will prefer using the
queryid anyway.

Ordinarily, we'd need to bump the extension version number for the latter
change. But since we already advanced pg_stat_statements' version number
from 1.1 to 1.2 in the 9.4 development cycle, it seems all right to just
redefine what 1.2 means.

Peter Geoghegan, reviewed by Pavel Stehule

(Tom Lane)
[f0d6f2027] 2014-01-27 15:37:54 -0500

It says "add a way" and "probably not of much interest for human use",
so it seems optional.

Thanks for the great feedback.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Sun, May 4, 2014 at 06:06:52PM +0400, Oleg Bartunov wrote:
> Bruce,
>
> you forgot Alexander Korotkov, who contributed jsonb_hash_ops opclass
> for GIN. Something like
> "Alexander Korotkov introduced an elegant jsonb_hash ops for GIN,
> which competes with MongoDB performance in contains operator".
>
> Here is a link to discussion -
> http://www.postgresql.org/message-id/53304439.8000602@dunslane.net

OK, added. As I remember Alexander's name was not in the initial commit
but mentioned in a later one, and I somehow missed that.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Sun, May 4, 2014 at 10:24:54AM -0400, Andrew Dunstan wrote:
>
> On 05/04/2014 10:12 AM, Petr Jelinek wrote:
> >On 04/05/14 14:46, Bruce Momjian wrote:
> >>I have completed the initial version of the 9.4 release notes. You can
> >>view them here:
> >>
> >> http://www.postgresql.org/docs/devel/static/release-9-4.html
> >>
> >>I will be adding additional markup in the next few days.
> >>
> >>Feedback expected and welcomed. I expect to be modifying this until we
> >>release 9.4 final. I have marked items where I need help with question
> >>marks.
> >>
> >
> >Nice work,
> >
> >one comment from me would be about jsonb:
> >
> >+ <listitem>
> >+ <para>
> >+ Add structured (non-text) data type (jsonb) for storing
> >JSON data (Oleg Bartunov, Teodor Sigaev, Peter Geoghegan and
> >Andrew Dunstan)
> >+ </para>
> >+
> >+ <para>
> >+ This data type allows faster indexing and access to json
> >keys/value pairs.
> >+ </para>
> >+ </listitem>
> >
> >I think the explanation should be expanded to say that this data
> >type also has generic indexing not just faster indexing.
> >
>
>
> It's also slightly ambiguous - it's not immediately clear that the
> "faster" also applies to the "access".

OK, how is this:

This data type allows for faster indexing and access to json
key/value pairs, as well as efficient indexing of all key/value
pairs in a JSON document.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Mon, May 5, 2014 at 09:10:11AM +0300, Heikki Linnakangas wrote:
> On 05/04/2014 03:46 PM, Bruce Momjian wrote:
> >I have completed the initial version of the 9.4 release notes.
>
> Thanks!
>
> >You can view them here:
> >
> > http://www.postgresql.org/docs/devel/static/release-9-4.html
> >
> >I will be adding additional markup in the next few days.
> >
> >Feedback expected and welcomed. I expect to be modifying this until we
> >release 9.4 final. I have marked items where I need help with question
> >marks.
>
> Two rather large changes to the B-tree algorithms are missing:
>
> * Fix race condition in B-tree page deletion (commit efada2b8)
>
> * Make the handling of interrupted B-tree page splits more robust
> (commit 40dae7ec)
>
> These changes are not visible to users, but they are good toknow for
> beta testers.

Thanks, added. I though these were fixes for 9.4-only bugs, not fixes
for earlier bugs. Thanks.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Mon, May 5, 2014 at 09:23:15AM +0300, Heikki Linnakangas wrote:
> On 05/04/2014 03:46 PM, Bruce Momjian wrote:
> >Auto-resize the catalog cache (Heikki Linnakangas)
> >
> >This reduces memory consumption for backends accessing only a few
> >tables, and improves performance for backend accessing many tables.
>
> Move this to "General performance" section.

OK, moved.

> >Improve spinlock speed on x86_64 CPUs (test on i386?) (Heikki Linnakangas)
>
> I believe this refers to commit b03d196b. The "test on i386" note
> can just be removed. Someone ought to test it on 32-bit i386 to see
> if the same change would be beneficial there, but that's a TODO item
> more than a release notes item. I doubt anyone's interested to spend
> time performance testing spinlocks on 32-bit i386, though, so I
> think we're going to just retain the current situation for the next
> decade.

Agreed. Text removed.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Sun, May 4, 2014 at 08:46:07AM -0400, Bruce Momjian wrote:
> I have completed the initial version of the 9.4 release notes. You can
> view them here:
>
> http://www.postgresql.org/docs/devel/static/release-9-4.html
>
> I will be adding additional markup in the next few days.
>
> Feedback expected and welcomed. I expect to be modifying this until we
> release 9.4 final. I have marked items where I need help with question
> marks.

I have updated output reflecting all hackers list feedback received so
far:

http://momjian.us/pgsql_docs/release-9-4.html

(The developer copy of the docs take a while to update.) Now on to the
markup additions.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

Bruce Momjian wrote:
> On Sun, May 4, 2014 at 03:49:27PM +0200, Andres Freund wrote:

> > + <listitem>
> > + <para>
> > + Add huge_pages configuration parameter to attempt to use huge translation look-aside buffer (TLB) pages on Linux (Christian Kruse,
> > + Richard Poole, Abhijit Menon-Sen)
> > + </para>
> >
> > I think this is too detailed - how about: "... to use huge pages ..."?
>
> I am not sure on this as the default is "try", but I updated the wording
> like your suggested:
>
> Add huge_pages configuration parameter to enable huge
> translation look-aside buffer (TLB) pages on Linux

Please see
http://www.postgresql.org/message-id/20140226161302.GD4759@eldon.alvh.no-ip.org
about the "TLB huge pages" terminology. Maybe "..enable huge MMU
pages..." as suggested by Peter G. in that sub-thread.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Mon, May 5, 2014 at 10:18:44AM -0400, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Sun, May 4, 2014 at 03:49:27PM +0200, Andres Freund wrote:
>
> > > + <listitem>
> > > + <para>
> > > + Add huge_pages configuration parameter to attempt to use huge translation look-aside buffer (TLB) pages on Linux (Christian Kruse,
> > > + Richard Poole, Abhijit Menon-Sen)
> > > + </para>
> > >
> > > I think this is too detailed - how about: "... to use huge pages ..."?
> >
> > I am not sure on this as the default is "try", but I updated the wording
> > like your suggested:
> >
> > Add huge_pages configuration parameter to enable huge
> > translation look-aside buffer (TLB) pages on Linux
>
> Please see
> http://www.postgresql.org/message-id/20140226161302.GD4759@eldon.alvh.no-ip.org
> about the "TLB huge pages" terminology. Maybe "..enable huge MMU
> pages..." as suggested by Peter G. in that sub-thread.

You are totally correct. I was referencing tlb from the _old_ name for
the variable, but didn't update the description when the variable was
renamed.

New text is:

Add huge_pages configuration parameter to use huge memory pages on Linux (Christian Kruse,
Richard Poole, Abhijit Menon-Sen)

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On 05/05/2014 09:38 AM, Bruce Momjian wrote:
> On Sun, May 4, 2014 at 10:24:54AM -0400, Andrew Dunstan wrote:
>> On 05/04/2014 10:12 AM, Petr Jelinek wrote:
>>> On 04/05/14 14:46, Bruce Momjian wrote:
>>>> I have completed the initial version of the 9.4 release notes. You can
>>>> view them here:
>>>>
>>>> http://www.postgresql.org/docs/devel/static/release-9-4.html
>>>>
>>>> I will be adding additional markup in the next few days.
>>>>
>>>> Feedback expected and welcomed. I expect to be modifying this until we
>>>> release 9.4 final. I have marked items where I need help with question
>>>> marks.
>>>>
>>> Nice work,
>>>
>>> one comment from me would be about jsonb:
>>>
>>> + <listitem>
>>> + <para>
>>> + Add structured (non-text) data type (jsonb) for storing
>>> JSON data (Oleg Bartunov, Teodor Sigaev, Peter Geoghegan and
>>> Andrew Dunstan)
>>> + </para>
>>> +
>>> + <para>
>>> + This data type allows faster indexing and access to json
>>> keys/value pairs.
>>> + </para>
>>> + </listitem>
>>>
>>> I think the explanation should be expanded to say that this data
>>> type also has generic indexing not just faster indexing.
>>>
>>
>> It's also slightly ambiguous - it's not immediately clear that the
>> "faster" also applies to the "access".
> OK, how is this:
>
> This data type allows for faster indexing and access to json
> key/value pairs, as well as efficient indexing of all key/value
> pairs in a JSON document.
>

No, I think you're missing the point of what I'm saying, and I think the
addition is at best misleading. I would avoid talk of key value pairs,
anyway, that's not all that's in a json document (it might be an array,
for example).

How about:

This data type allows for faster access to values in the json document and faster and more useful indexing of json.

cheers

andrew

On Mon, May 5, 2014 at 11:28:21AM -0400, Andrew Dunstan wrote:
> No, I think you're missing the point of what I'm saying, and I think
> the addition is at best misleading. I would avoid talk of key value
> pairs, anyway, that's not all that's in a json document (it might be
> an array, for example).
>
> How about:
>
> This data type allows for faster access to values in the json document and faster and more useful indexing of json.

OK, I used you wording. You are right I didn't understand it.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On 05/04/2014 05:46 AM, Bruce Momjian wrote:
> I have completed the initial version of the 9.4 release notes. You can
> view them here:
>
> http://www.postgresql.org/docs/devel/static/release-9-4.html
>
> I will be adding additional markup in the next few days.
>
> Feedback expected and welcomed. I expect to be modifying this until we
> release 9.4 final. I have marked items where I need help with question
> marks.
>

Major enhancement list:

Per discussion on the -advocacy list, the features we've picked out as
"major enhancements" for advocacy reasons this round are:

* Materialized Views (because with refresh concurrently, MatViews are
now useful, which they weren't, very, in 9.3)

* Logical Decoding/Changeset Extraction which we're calling "Data Change
Streaming API" in the advocacy stuff. Not sure if you want to use that
name in the technical realease notes.

* Dynamic Background Workers (this one is a major feature, but won't be
front-listed in advocacy doc because it's hard to explain and nobody's
built anything cool with it yet. But it should go under major
enhancements in the release notes)

* JSONB and related features (such as indexing)

* ALTER SYSTEM SET

Lemme know if you need description text for any of the above.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On Mon, May 5, 2014 at 10:40:29AM -0700, Josh Berkus wrote:
> On 05/04/2014 05:46 AM, Bruce Momjian wrote:
> > I have completed the initial version of the 9.4 release notes. You can
> > view them here:
> >
> > http://www.postgresql.org/docs/devel/static/release-9-4.html
> >
> > I will be adding additional markup in the next few days.
> >
> > Feedback expected and welcomed. I expect to be modifying this until we
> > release 9.4 final. I have marked items where I need help with question
> > marks.
> >
>
> Major enhancement list:
>
> Per discussion on the -advocacy list, the features we've picked out as
> "major enhancements" for advocacy reasons this round are:
>
> * Materialized Views (because with refresh concurrently, MatViews are
> now useful, which they weren't, very, in 9.3)
>
> * Logical Decoding/Changeset Extraction which we're calling "Data Change
> Streaming API" in the advocacy stuff. Not sure if you want to use that
> name in the technical realease notes.
>
> * Dynamic Background Workers (this one is a major feature, but won't be
> front-listed in advocacy doc because it's hard to explain and nobody's
> built anything cool with it yet. But it should go under major
> enhancements in the release notes)
>
> * JSONB and related features (such as indexing)
>
> * ALTER SYSTEM SET
>
> Lemme know if you need description text for any of the above.

OK, great! Once I have the markup done, I will beef up the descriptions
if needed and copy the text up to the major items section so we have
that all ready for beta.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Mon, May 5, 2014 at 8:28 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> How about:
>
> This data type allows for faster access to values in the json document
> and faster and more useful indexing of json.

We should refer to the fact that jsonb is internally typed. This isn't
all that obvious now, but it is evident for example when you sort a
set of raw scalar numeric jsonb values, which has a sane ordering (the
implementation invokes numeric_cmp()). You also get an internal,
per-number-scalar display scale, just like the numeric type proper.
I'm not all that sure about how to go about succinctly expressing
this, but clearly it's important.

--
Peter Geoghegan

On Mon, May 5, 2014 at 10:58:57AM -0700, Peter Geoghegan wrote:
> On Mon, May 5, 2014 at 8:28 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> > How about:
> >
> > This data type allows for faster access to values in the json document
> > and faster and more useful indexing of json.
>
> We should refer to the fact that jsonb is internally typed. This isn't
> all that obvious now, but it is evident for example when you sort a
> set of raw scalar numeric jsonb values, which has a sane ordering (the
> implementation invokes numeric_cmp()). You also get an internal,
> per-number-scalar display scale, just like the numeric type proper.
> I'm not all that sure about how to go about succinctly expressing
> this, but clearly it's important.

How about:

JSONB values are also mapped to SQL scalar data types, rather
than being treated always as strings.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On 05/05/2014 11:31 AM, Bruce Momjian wrote:
> JSONB values are also mapped to SQL scalar data types, rather
> than being treated always as strings.

+ ... allowing for correct sorting of JSON according to internal datums.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On Mon, May 5, 2014 at 11:31 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> JSONB values are also mapped to SQL scalar data types, rather
> than being treated always as strings.

Something like that. Perhaps you should just go with what the
documentation says: "Primitive JSON types described by RFC 7159 are
effectively internally mapped onto native PostgreSQL types."

The fact that the default B-Tree operator class defines a type-wise
ordering is beside the point. That's just currently the most obvious
way in which this "shadow typing" is evident. At some point we're
going to have to figure out ways to manipulate jsonb using shadow type
specific operators or functions, so you can for example "extract"
actual numeric values easily. I don't want users to assume that those
don't exist right now due to a fundamental limitation of our
implementation.

--
Peter Geoghegan

On 05/05/2014 02:33 PM, Josh Berkus wrote:
> On 05/05/2014 11:31 AM, Bruce Momjian wrote:
>> JSONB values are also mapped to SQL scalar data types, rather
>> than being treated always as strings.
> + ... allowing for correct sorting of JSON according to internal datums.
>

The problem is that at least in one sense that's not what we're doing.
The canonical ordering of object keys is not at all standard lexical
ordering.

I really don't think this is Release Notes material. The fact that jsonb
maps scalar values to internal postgres types is an implementation artefact.

cheers

andrew

On Mon, May 5, 2014 at 1:13 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> The fact that jsonb maps scalar values to internal postgres types is an
> implementation artefact.

I wouldn't go that far, but I take your point. The fact that the
primitive/scalar JSON types are in a very real sense strongly typed is
a very important detail, though. The fact that what became jsonb is
like a nested, typed hstore has always been prominently emphasized,
for good reasons.

--
Peter Geoghegan

On Mon, May 5, 2014 at 10:40:29AM -0700, Josh Berkus wrote:
> Major enhancement list:
>
> Per discussion on the -advocacy list, the features we've picked out as
> "major enhancements" for advocacy reasons this round are:
>
> * Materialized Views (because with refresh concurrently, MatViews are
> now useful, which they weren't, very, in 9.3)
>
> * Logical Decoding/Changeset Extraction which we're calling "Data Change
> Streaming API" in the advocacy stuff. Not sure if you want to use that
> name in the technical realease notes.
>
> * Dynamic Background Workers (this one is a major feature, but won't be
> front-listed in advocacy doc because it's hard to explain and nobody's
> built anything cool with it yet. But it should go under major
> enhancements in the release notes)
>
> * JSONB and related features (such as indexing)
>
> * ALTER SYSTEM SET
>
> Lemme know if you need description text for any of the above.

OK, I added doc links and this list of major features. You can see the
results here:

http://momjian.us/pgsql_docs/release-9-4.html

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Sun, May 4, 2014 at 6:49 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> + <listitem>
> + <para>
> + Have pg_stat_statements use a flat file for query text storage, allowing higher limits (Peter Geoghegan)
> + </para>
> +
> + <para>
> + Also add the ability to retrieve all pg_stat_statements information except the query text. This allows programs to reuse the query
> + text already retrieved by referencing queryid.
> + </para>
> + </listitem>
>
> This isn't an optional thing, is it?

This is intended to be used by time-series monitoring tools that
aggregate and graph pg_stat_statements data temporally. They usually
won't need query texts, and so can only retrieve them lazily. The
pg_stat_statements view presents exactly the same interface for ad-hoc
querying, though.

The point of the first item is that there is no longer *any*
limitation on the size of stored query texts. They are no longer
truncated to track_activity_query_size bytes. The shared memory
overhead is also decreased substantially, allowing us to increase the
default pg_stat_statements.max setting from 1,000 to 5,000, while
still reducing the overall shared memory overhead (assuming a default
track_activity_query_size). I think that the removal of the
limitation, and the substantial lowering of the per-entry footprint
should both be explicitly noted.

--
Peter Geoghegan

On Mon, May 5, 2014 at 02:23:13PM -0700, Peter Geoghegan wrote:
> On Sun, May 4, 2014 at 6:49 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > + <listitem>
> > + <para>
> > + Have pg_stat_statements use a flat file for query text storage, allowing higher limits (Peter Geoghegan)
> > + </para>
> > +
> > + <para>
> > + Also add the ability to retrieve all pg_stat_statements information except the query text. This allows programs to reuse the query
> > + text already retrieved by referencing queryid.
> > + </para>
> > + </listitem>
> >
> > This isn't an optional thing, is it?
>
> This is intended to be used by time-series monitoring tools that
> aggregate and graph pg_stat_statements data temporally. They usually
> won't need query texts, and so can only retrieve them lazily. The
> pg_stat_statements view presents exactly the same interface for ad-hoc
> querying, though.
>
> The point of the first item is that there is no longer *any*
> limitation on the size of stored query texts. They are no longer
> truncated to track_activity_query_size bytes. The shared memory
> overhead is also decreased substantially, allowing us to increase the
> default pg_stat_statements.max setting from 1,000 to 5,000, while
> still reducing the overall shared memory overhead (assuming a default
> track_activity_query_size). I think that the removal of the
> limitation, and the substantial lowering of the per-entry footprint
> should both be explicitly noted.

We rarely get into specific numers like this. It says "higher limit(s)" and
hopefully that is enough. If you want to create a documentation 'id' I
can like to that for the "higher limits" text.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Mon, May 5, 2014 at 10:58:57AM -0700, Peter Geoghegan wrote:
> On Mon, May 5, 2014 at 8:28 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> > How about:
> >
> > This data type allows for faster access to values in the json document
> > and faster and more useful indexing of json.
>
> We should refer to the fact that jsonb is internally typed. This isn't
> all that obvious now, but it is evident for example when you sort a
> set of raw scalar numeric jsonb values, which has a sane ordering (the
> implementation invokes numeric_cmp()). You also get an internal,
> per-number-scalar display scale, just like the numeric type proper.
> I'm not all that sure about how to go about succinctly expressing
> this, but clearly it's important.

Current text is:

Add structured (non-text) data type (JSONB) for storing JSON data (Oleg
Bartunov, Teodor Sigaev, Alexander Korotkov, Peter Geoghegan, and Andrew
Dunstan)

This allows for faster access to values in the JSON document and faster
and more useful indexing of JSON. JSONB values are also typed as
appropriate scalar SQL types.

Is that OK?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Mon, May 5, 2014 at 4:14 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> We rarely get into specific numers like this. It says "higher limit(s)" and
> hopefully that is enough. If you want to create a documentation 'id' I
> can like to that for the "higher limits" text.

You don't have to mention a number. Just the fact that there is now
*no* limit on stored query text length, which is the point. It's also
nice that the per-entry shared memory overhead is much lower, which as
I said I think warrants a mention in passing.

--
Peter Geoghegan

On Mon, May 5, 2014 at 4:16 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> This allows for faster access to values in the JSON document and faster
> and more useful indexing of JSON. JSONB values are also typed as
> appropriate scalar SQL types.
>
> Is that OK?

That seems reasonable.

--
Peter Geoghegan

On 05/05/2014 07:16 PM, Bruce Momjian wrote:
> On Mon, May 5, 2014 at 10:58:57AM -0700, Peter Geoghegan wrote:
>> On Mon, May 5, 2014 at 8:28 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>> How about:
>>>
>>> This data type allows for faster access to values in the json document
>>> and faster and more useful indexing of json.
>> We should refer to the fact that jsonb is internally typed. This isn't
>> all that obvious now, but it is evident for example when you sort a
>> set of raw scalar numeric jsonb values, which has a sane ordering (the
>> implementation invokes numeric_cmp()). You also get an internal,
>> per-number-scalar display scale, just like the numeric type proper.
>> I'm not all that sure about how to go about succinctly expressing
>> this, but clearly it's important.
> Current text is:
>
> Add structured (non-text) data type (JSONB) for storing JSON data (Oleg
> Bartunov, Teodor Sigaev, Alexander Korotkov, Peter Geoghegan, and Andrew
> Dunstan)
>
> This allows for faster access to values in the JSON document and faster
> and more useful indexing of JSON. JSONB values are also typed as
> appropriate scalar SQL types.
>
> Is that OK?
>

No. If you must say something then start the last sentence with "Scalar
values in JSONB documents are typed ...". Personally, I think we're
making too much of this. After all, everything that's not a number or
boolean is typed as text (just as it is in JSON). We don't, for example,
map anything to timestamp types.

cheers

andrew

On Mon, May 5, 2014 at 4:26 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> After all, everything that's not a number or boolean is typed as text (just
> as it is in JSON). We don't, for example, map anything to timestamp types.

JSON doesn't have a timestamp primitive type. Of those types that it
has, their internal representation, and their behavior in all relevant
contexts is more or less consistent with what you'd expect of the
mapped-to type. I think that's a very significant point - you will be
able to extract numerics, and manipulate them as numerics in a future
release without using text casting hacks. null values are not typed as
text either. Besides, the on-disk representation of numeric is quite a
lot more compact, and this could easily matter.

--
Peter Geoghegan

On 05/05/2014 07:34 PM, Peter Geoghegan wrote:
> On Mon, May 5, 2014 at 4:26 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> After all, everything that's not a number or boolean is typed as text (just
>> as it is in JSON). We don't, for example, map anything to timestamp types.
> JSON doesn't have a timestamp primitive type. Of those types that it
> has, their internal representation, and their behavior in all relevant
> contexts is more or less consistent with what you'd expect of the
> mapped-to type. I think that's a very significant point - you will be
> able to extract numerics, and manipulate them as numerics in a future
> release without using text casting hacks. null values are not typed as
> text either. Besides, the on-disk representation of numeric is quite a
> lot more compact, and this could easily matter.
>
>

OK, but if we must talk about it then at least we should do so with
precision and accuracy. The current wording is too sloppy.

cheers

andrew

On Mon, May 5, 2014 at 04:20:26PM -0700, Peter Geoghegan wrote:
> On Mon, May 5, 2014 at 4:14 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > We rarely get into specific numers like this. It says "higher limit(s)" and
> > hopefully that is enough. If you want to create a documentation 'id' I
> > can like to that for the "higher limits" text.
>
> You don't have to mention a number. Just the fact that there is now
> *no* limit on stored query text length, which is the point. It's also
> nice that the per-entry shared memory overhead is much lower, which as
> I said I think warrants a mention in passing.

OK, I understand now. I also split the item into two separate ones so I
could highlight things. Please see the new ouput --- I ended up
creating a pg_stat_statements section because there are now three items:

http://momjian.us/pgsql_docs/release-9-4.html

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Mon, May 5, 2014 at 5:13 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> OK, I understand now. I also split the item into two separate ones so I
> could highlight things. Please see the new ouput --- I ended up
> creating a pg_stat_statements section because there are now three items:
>
> http://momjian.us/pgsql_docs/release-9-4.html

I agree with the need for a separate section.

You wrote:

"This allows programs to reuse the query text already retrieved by
referencing queryid."

That's perhaps a little misleading, since queryid should virtually
always match the original normalized query text (so we only have to
get a new query text when there is a new queryid). I probably would
have phrased it:

"This allows monitoring tools to only fetch query texts for newly
observe entries, as determined by queryid"

--
Peter Geoghegan

On Mon, May 5, 2014 at 05:22:59PM -0700, Peter Geoghegan wrote:
> On Mon, May 5, 2014 at 5:13 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > OK, I understand now. I also split the item into two separate ones so I
> > could highlight things. Please see the new ouput --- I ended up
> > creating a pg_stat_statements section because there are now three items:
> >
> > http://momjian.us/pgsql_docs/release-9-4.html
>
>
> I agree with the need for a separate section.
>
> You wrote:
>
> "This allows programs to reuse the query text already retrieved by
> referencing queryid."
>
> That's perhaps a little misleading, since queryid should virtually
> always match the original normalized query text (so we only have to
> get a new query text when there is a new queryid). I probably would
> have phrased it:
>
> "This allows monitoring tools to only fetch query texts for newly
> observe entries, as determined by queryid"

OK, done.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

2014-05-05 Bruce Momjian <bruce(at)momjian(dot)us>:

> On Mon, May 5, 2014 at 10:40:29AM -0700, Josh Berkus wrote:
>
>> * ALTER SYSTEM SET
>>
>> Lemme know if you need description text for any of the above.
>
> OK, great! Once I have the markup done, I will beef up the descriptions
> if needed and copy the text up to the major items section so we have
> that all ready for beta.

“Add SQL-level command ALTER SYSTEM command [..]”

Using “command” twice sounds weird to my ears. Wouldn’t leaving out
the second instance be better?

Nicolas

--
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?

> I have completed the initial version of the 9.4 release notes. You can
> view them here:
>
> http://www.postgresql.org/docs/devel/static/release-9-4.html
>
> I will be adding additional markup in the next few days.
>
> Feedback expected and welcomed. I expect to be modifying this until we
> release 9.4 final. I have marked items where I need help with question
> marks.

--------------------------------------------------------------------------------------------
E.1.3.7.1. System Information Functions

Add functions for error-free pg_class, pg_proc, pg_type, and pg_operator lookups (Yugo Nagata, Nozomi Anzai, Robert Haas)

For example, to_regclass() does error-free lookups of pg_class, and returns NULL for lookup failures.
--------------------------------------------------------------------------------------------

Probably "error-free" is too strong wording because these functions
are not actualy error free.

test=# select to_regclass('a.b.c.d');
ERROR: improper relation name (too many dotted names): a.b.c.d
STATEMENT: select to_regclass('a.b.c.d');

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

From: "Bruce Momjian" <bruce(at)momjian(dot)us>
>I have completed the initial version of the 9.4 release notes. You can
> view them here:
>
> http://www.postgresql.org/docs/devel/static/release-9-4.html
>
> Feedback expected and welcomed. I expect to be modifying this until we
> release 9.4 final. I have marked items where I need help with question
> marks.

Could you add the following item, client-only installation on Windows, if
it's appropriate for release note? It will be useful for those like
EnterpriseDB who develop products derived from PostgreSQL.

https://commitfest.postgresql.org/action/patch_view?id=1326

Regards
MauMau

On Thu, May 8, 2014 at 10:50 AM, MauMau <maumau307(at)gmail(dot)com> wrote:
> Could you add the following item, client-only installation on Windows, if
> it's appropriate for release note?

I think that it is appropriate.

--
Peter Geoghegan

On Fri, May 9, 2014 at 2:50 AM, MauMau <maumau307(at)gmail(dot)com> wrote:
> From: "Bruce Momjian" <bruce(at)momjian(dot)us>
>>
>> I have completed the initial version of the 9.4 release notes. You can
>> view them here:
>>
>> http://www.postgresql.org/docs/devel/static/release-9-4.html
>>
>> Feedback expected and welcomed. I expect to be modifying this until we
>> release 9.4 final. I have marked items where I need help with question
>> marks.
>
>
> Could you add the following item, client-only installation on Windows, if
> it's appropriate for release note? It will be useful for those like
> EnterpriseDB who develop products derived from PostgreSQL.
>
> https://commitfest.postgresql.org/action/patch_view?id=1326
+1. Thanks for pointing that out as well!
--
Michael

Hi,

I've attached a fair number of fixes for the current state of the
release notes. Many of them are fixing factual errors, others are more
minors.
I think the whole 'logical decoding' section will need an entire
rewrite, but I'll do that separately.

I've added a couple of <!-- FIXME --> for things that are clearly
unfinished.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Tue, May 6, 2014 at 03:53:54PM +0200, Nicolas Barbier wrote:
> 2014-05-05 Bruce Momjian <bruce(at)momjian(dot)us>:
>
> > On Mon, May 5, 2014 at 10:40:29AM -0700, Josh Berkus wrote:
> >
> >> * ALTER SYSTEM SET
> >>
> >> Lemme know if you need description text for any of the above.
> >
> > OK, great! Once I have the markup done, I will beef up the descriptions
> > if needed and copy the text up to the major items section so we have
> > that all ready for beta.
>
> “Add SQL-level command ALTER SYSTEM command [..]”
>
> Using “command” twice sounds weird to my ears. Wouldn’t leaving out
> the second instance be better?

Agreed. Second "command" removed.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Thu, May 8, 2014 at 10:17:27AM +0900, Tatsuo Ishii wrote:
> > I have completed the initial version of the 9.4 release notes. You can
> > view them here:
> >
> > http://www.postgresql.org/docs/devel/static/release-9-4.html
> >
> > I will be adding additional markup in the next few days.
> >
> > Feedback expected and welcomed. I expect to be modifying this until we
> > release 9.4 final. I have marked items where I need help with question
> > marks.
>
> --------------------------------------------------------------------------------------------
> E.1.3.7.1. System Information Functions
>
> Add functions for error-free pg_class, pg_proc, pg_type, and pg_operator lookups (Yugo Nagata, Nozomi Anzai, Robert Haas)
>
> For example, to_regclass() does error-free lookups of pg_class, and returns NULL for lookup failures.
> --------------------------------------------------------------------------------------------
>
> Probably "error-free" is too strong wording because these functions
> are not actualy error free.
>
> test=# select to_regclass('a.b.c.d');
> ERROR: improper relation name (too many dotted names): a.b.c.d
> STATEMENT: select to_regclass('a.b.c.d');

Agreed. New text:

Add functions for <structname>pg_class</>,
<structname>pg_proc</>, <structname>pg_type</>, and
<structname>pg_operator</> lookups that do not generate errors for
non-existent objects (Yugo Nagata, Nozomi Anzai,
Robert Haas)

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Fri, May 9, 2014 at 02:50:05AM +0900, MauMau wrote:
> From: "Bruce Momjian" <bruce(at)momjian(dot)us>
> >I have completed the initial version of the 9.4 release notes. You can
> >view them here:
> >
> >http://www.postgresql.org/docs/devel/static/release-9-4.html
> >
> >Feedback expected and welcomed. I expect to be modifying this until we
> >release 9.4 final. I have marked items where I need help with question
> >marks.
>
> Could you add the following item, client-only installation on
> Windows, if it's appropriate for release note? It will be useful
> for those like EnterpriseDB who develop products derived from
> PostgreSQL.
>
> https://commitfest.postgresql.org/action/patch_view?id=1326

Agreed, added:

Allow client-only installs for <acronym>MSVC</>
(Windows) builds (MauMau)

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Fri, May 9, 2014 at 04:53:18PM +0200, Andres Freund wrote:
> Hi,
>
> I've attached a fair number of fixes for the current state of the
> release notes. Many of them are fixing factual errors, others are more
> minors.
> I think the whole 'logical decoding' section will need an entire
> rewrite, but I'll do that separately.
>
> I've added a couple of <!-- FIXME --> for things that are clearly
> unfinished.

Slightly adjusted attached patch applied. Thanks. Let me know if you
have any follow-on changes.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On 4 May 2014 13:46, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> I have completed the initial version of the 9.4 release notes. You can
> view them here:
>
> http://www.postgresql.org/docs/devel/static/release-9-4.html
>
> I will be adding additional markup in the next few days.
>
> Feedback expected and welcomed. I expect to be modifying this until we
> release 9.4 final. I have marked items where I need help with question
> marks.
>

In a few places, I think "updateable" should be spelled "updatable"
for consistency with the rest of the documentation (although I think
both spellings are actually correct).

===
Allow the updating of views where only some columns are
auto-updateable (Dean Rasheed)

Previously the presence of a non-auto-updateable column prevented all
columns from being auto-updated. Deletes are now supported on suitable
views even if no auto-updateable columns are present.
===

I think that puts too much emphasis on deletes, and could be
misinterpreted. How about something like this:

Allow views to be automatically updatable even if they contain some
non-updatable columns (Dean Rasheed)

Previously the presence of non-updatable columns such as expressions,
literals and functions prevented automatic updates. Now INSERTs,
UPDATEs and DELETEs are supported, provided that they do not attempt
to assign new values to any of the non-updatable columns.

Regards,
Dean

On Wed, May 14, 2014 at 08:33:15AM +0100, Dean Rasheed wrote:
> On 4 May 2014 13:46, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > I have completed the initial version of the 9.4 release notes. You can
> > view them here:
> >
> > http://www.postgresql.org/docs/devel/static/release-9-4.html
> >
> > I will be adding additional markup in the next few days.
> >
> > Feedback expected and welcomed. I expect to be modifying this until we
> > release 9.4 final. I have marked items where I need help with question
> > marks.
> >
>
> In a few places, I think "updateable" should be spelled "updatable"
> for consistency with the rest of the documentation (although I think
> both spellings are actually correct).
>
>
> ===
> Allow the updating of views where only some columns are
> auto-updateable (Dean Rasheed)
>
> Previously the presence of a non-auto-updateable column prevented all
> columns from being auto-updated. Deletes are now supported on suitable
> views even if no auto-updateable columns are present.
> ===
>
> I think that puts too much emphasis on deletes, and could be
> misinterpreted. How about something like this:
>
> Allow views to be automatically updatable even if they contain some
> non-updatable columns (Dean Rasheed)
>
> Previously the presence of non-updatable columns such as expressions,
> literals and functions prevented automatic updates. Now INSERTs,
> UPDATEs and DELETEs are supported, provided that they do not attempt
> to assign new values to any of the non-updatable columns.

Agreed. Adjusted attached patch applied. I was never happy with the
previous awkward auto-update wording.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On 14 May 2014 15:07, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Wed, May 14, 2014 at 08:33:15AM +0100, Dean Rasheed wrote:
>> On 4 May 2014 13:46, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> > I have completed the initial version of the 9.4 release notes. You can
>> > view them here:
>> >
>> > http://www.postgresql.org/docs/devel/static/release-9-4.html
>> >
>> > I will be adding additional markup in the next few days.
>> >
>> > Feedback expected and welcomed. I expect to be modifying this until we
>> > release 9.4 final. I have marked items where I need help with question
>> > marks.
>> >
>>
>> In a few places, I think "updateable" should be spelled "updatable"
>> for consistency with the rest of the documentation (although I think
>> both spellings are actually correct).
>>
>>
>> ===
>> Allow the updating of views where only some columns are
>> auto-updateable (Dean Rasheed)
>>
>> Previously the presence of a non-auto-updateable column prevented all
>> columns from being auto-updated. Deletes are now supported on suitable
>> views even if no auto-updateable columns are present.
>> ===
>>
>> I think that puts too much emphasis on deletes, and could be
>> misinterpreted. How about something like this:
>>
>> Allow views to be automatically updatable even if they contain some
>> non-updatable columns (Dean Rasheed)
>>
>> Previously the presence of non-updatable columns such as expressions,
>> literals and functions prevented automatic updates. Now INSERTs,
>> UPDATEs and DELETEs are supported, provided that they do not attempt
>> to assign new values to any of the non-updatable columns.
>
> Agreed. Adjusted attached patch applied. I was never happy with the
> previous awkward auto-update wording.
>

Thanks. There's a typo in the new text though --- "cals" should be "calls".

Regards,
Dean

On Wed, May 14, 2014 at 05:40:04PM +0100, Dean Rasheed wrote:
> > Agreed. Adjusted attached patch applied. I was never happy with the
> > previous awkward auto-update wording.
> >
>
> Thanks. There's a typo in the new text though --- "cals" should be "calls".

Thanks, fixed.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On 2014-05-04 08:46:07 -0400, Bruce Momjian wrote:
> I have completed the initial version of the 9.4 release notes. You can
> view them here:
>
> http://www.postgresql.org/docs/devel/static/release-9-4.html
>
> I will be adding additional markup in the next few days.
>
> Feedback expected and welcomed. I expect to be modifying this until we
> release 9.4 final. I have marked items where I need help with question
> marks.

This time I started reading from the end. I think I've fixed most of the
questionable things (i.e. ? or FIXMEs) left.

I am not really sure how to rewrite the notes for the logical decoding
stuff into a more appropriate format for the release notes. Currently it
seems to describe too many details and not enough overview. It's also
probably too long.

How about letting it keep it's <sect4> but remove the <itemizedlist> and
put a short explanation about the individual parts into a following
<para> or two? That'd require a name after a <sect4> which normally
isn't done...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Andres Freund-3 wrote
> On 2014-05-04 08:46:07 -0400, Bruce Momjian wrote:
>> I have completed the initial version of the 9.4 release notes. You can
>> view them here:
>>
>> http://www.postgresql.org/docs/devel/static/release-9-4.html
>>
>> I will be adding additional markup in the next few days.
>>
>> Feedback expected and welcomed. I expect to be modifying this until we
>> release 9.4 final. I have marked items where I need help with question
>> marks.
>
> This time I started reading from the end. I think I've fixed most of the
> questionable things (i.e. ? or FIXMEs) left.
>
> I am not really sure how to rewrite the notes for the logical decoding
> stuff into a more appropriate format for the release notes. Currently it
> seems to describe too many details and not enough overview. It's also
> probably too long.
>
> How about letting it keep it's
> <sect4>
> but remove the
> <itemizedlist>
> and
> put a short explanation about the individual parts into a following
> <para>
> or two? That'd require a name after a
> <sect4>
> which normally
> isn't done...
>
> Greetings,
>
> Andres Freund

Some errors and suggestions - my apologizes for the format as I do not have
a proper patching routine setup.

Patch Review - Top to Bottom (mostly, I think...)

s/constraints's/constraint/ - possessive not needed here, it is a property
of the constraint, not owned by it.

s/plannet/planner

<command>DISCARD ALL</> now also discards the states of sequences.
change to
<command>DISCARD ALL</> now also discards sequence state.

IIUC: Logical decoding allows for streaming of statement-scoped database
changes.

Add function pg_filenode_relation() to more efficiently lookup relations via
their filenode.

This allows one to declare array_agg()-like aggregates using SQL.

IIUC: Remove line length restrictions from pgbench.

These are not in the patch but from my quick scan of the online release
notes - top to bottom:

then conditionally additional adjacent whitespace if not in FX mode
->
then, conditionally, remove additional adjacent whitespace if not in FX
mode.
(I presume those conditions are noted in the documentation somewhere)

For example, previously format string space-space-space would consume only
the first space in ' 12', while it will not consume all three characters.
->
For example, the format string space-space-space previously consumed only
the first space in 'space-space-12' whereas now it will consume all three
characters.

style: add comma -> Previously[,] empty arrays were returned (occurs
frequently but is minor)

style: NULL VARIADIC function arguments are now disallowed
->
Disallow NULL VARIADIC function arguments
(most of the notes are verb-leading in structure)

During immediate shutdown, send uncatchable termination <- kill the comma

In contrast to local_preload_libraries, this parameter can load any shared
library <- shoot the comma

The linking on this one is odd:
Have Windows ASCII-encoded databases and server process (e.g. postmaster)
emit messages in the LC_CTYPE-defined language (Alexander Law, Noah Misch)

Add ROWS FROM() syntax to allow horizontal concatenation of set-returning
functions in the FROM-clause (Andrew Gierth)
-> Maybe a note about using this to avoid least-common-multiple expansion?

Add WITH ORDINALITY syntax which numbers rows returned from FROM-clause
functions
->
Add WITH ORDINALITY syntax to number the rows returned by FROM-clause
functions.

???
DISCARD ALL will now also discard such information.
->
DISCARD ALL now also invokes this command.

be converted to NULL in in CSV mode <- strike one of the "in"s

[I got no clue on this pair... but recommend someone rewrite it]
Improve the internal definition of system relations (Andres Freund, Robert
Haas)
Previously, relations once moved into the system catalog schema could no
longer be modified or dropped.

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/9-4-release-notes-tp5802343p5804163.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.

On 05/05/2014 07:26 PM, Andrew Dunstan wrote:
>
> On 05/05/2014 07:16 PM, Bruce Momjian wrote:
>> Current text is:
>>
>> Add structured (non-text) data type (JSONB) for storing JSON data
>> (Oleg
>> Bartunov, Teodor Sigaev, Alexander Korotkov, Peter Geoghegan, and
>> Andrew
>> Dunstan)
>>
>> This allows for faster access to values in the JSON document and
>> faster
>> and more useful indexing of JSON. JSONB values are also typed as
>> appropriate scalar SQL types.
>>
>> Is that OK?
>>
>
>
> No. If you must say something then start the last sentence with
> "Scalar values in JSONB documents are typed ...".

I still think we should make this change. Does anyone object if I do?

cheers

andrew

On Fri, May 16, 2014 at 02:10:40AM +0200, Andres Freund wrote:
> On 2014-05-04 08:46:07 -0400, Bruce Momjian wrote:
> > I have completed the initial version of the 9.4 release notes. You can
> > view them here:
> >
> > http://www.postgresql.org/docs/devel/static/release-9-4.html
> >
> > I will be adding additional markup in the next few days.
> >
> > Feedback expected and welcomed. I expect to be modifying this until we
> > release 9.4 final. I have marked items where I need help with question
> > marks.
>
> This time I started reading from the end. I think I've fixed most of the
> questionable things (i.e. ? or FIXMEs) left.

I adjusted your patch and applied it. Thanks.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Fri, May 16, 2014 at 02:10:40AM +0200, Andres Freund wrote:
> I am not really sure how to rewrite the notes for the logical decoding
> stuff into a more appropriate format for the release notes. Currently it
> seems to describe too many details and not enough overview. It's also
> probably too long.
>
> How about letting it keep it's <sect4> but remove the <itemizedlist> and
> put a short explanation about the individual parts into a following
> <para> or two? That'd require a name after a <sect4> which normally
> isn't done...

I am not sure how to improve it either. The features adds config
variable changes, a new table option, and new binary --- I think listing
those separately is good. I am not sure it can be improved without
making it appear disjointed.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Thu, May 15, 2014 at 06:08:47PM -0700, David G Johnston wrote:
> Some errors and suggestions - my apologizes for the format as I do not have
> a proper patching routine setup.
>
> Patch Review - Top to Bottom (mostly, I think...)

I have made your suggested adjustments in the attached applied patch.

> Add ROWS FROM() syntax to allow horizontal concatenation of set-returning
> functions in the FROM-clause (Andrew Gierth)
> -> Maybe a note about using this to avoid least-common-multiple expansion?

Sorry, I do not understand this.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Sun, May 18, 2014 at 04:08:41PM -0400, Andrew Dunstan wrote:
>
> On 05/05/2014 07:26 PM, Andrew Dunstan wrote:
> >
> >On 05/05/2014 07:16 PM, Bruce Momjian wrote:
> >>Current text is:
> >>
> >> Add structured (non-text) data type (JSONB) for storing JSON
> >>data (Oleg
> >> Bartunov, Teodor Sigaev, Alexander Korotkov, Peter
> >>Geoghegan, and Andrew
> >> Dunstan)
> >>
> >> This allows for faster access to values in the JSON document
> >>and faster
> >> and more useful indexing of JSON. JSONB values are also typed as
> >> appropriate scalar SQL types.
> >>
> >>Is that OK?
> >>
> >
> >
> >No. If you must say something then start the last sentence with
> >"Scalar values in JSONB documents are typed ...".
>
>
> I still think we should make this change. Does anyone object if I do?

OK, I have adjusted it with the attached applied patch. Feel free to
adjust it yourself as well.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Thu, May 15, 2014 at 06:08:47PM -0700, David G Johnston wrote:
> Some errors and suggestions - my apologizes for the format as I do not have
> a proper patching routine setup.
>

Sorry, let me address some items I skipped on your list:

> IIUC: Logical decoding allows for streaming of statement-scoped database
> changes.

I think Logical decoding does more than statement-scoped database
changes, e.g. it can enable multi-master without triggers. I am
hesitant to mention specific items in the release notes for that reason.

> IIUC: Remove line length restrictions from pgbench.

Uh, there is a specific place we removed the ne length restriction in
pg_bench.

> style: add comma -> Previously[,] empty arrays were returned (occurs
> frequently but is minor)

Thanks for the comma adjustments --- I can't decide on that sometimes.

FYI, the most frequently updated doc build is here:

http://momjian.us/pgsql_docs/release-9-4.html

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Mon, May 19, 2014 at 10:23 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Thu, May 15, 2014 at 06:08:47PM -0700, David G Johnston wrote:
> > Some errors and suggestions - my apologizes for the format as I do not
> have
> > a proper patching routine setup.
> >
>
> Sorry, let me address some items I skipped on your list:
>
> > IIUC: Logical decoding allows for streaming of statement-scoped database
> > changes.
>
> I think Logical decoding does more than statement-scoped database
> changes, e.g. it can enable multi-master without triggers. I am
> hesitant to mention specific items in the release notes for that reason.
>

​Yeah, probably need to look at this as a bigger unit of work and better
understand it first. But
"​to be optionally streamed in a configurable format" seems too vague.

> > IIUC: Remove line length restrictions from pgbench.

> Uh, there is a specific place we removed the ne length restriction in
> pg_bench.
>

​​I simply interpreted:

​Allow pgbench to process script files of any line length (Sawada Masahiko)

The previous line limit was BUFSIZ.
​
"script files of any line length" just doesn't sound right to me; and if my
re-wording is wrong then it also does not actually communicate what was
changed very well.

>
> > style: add comma -> Previously[,] empty arrays were returned (occurs
> > frequently but is minor)
>
> Thanks for the comma adjustments --- I can't decide on that sometimes.
>

​Not a grammar expert by any means but there are generally two uses of
"previously".

He previously removed that from the build.
Previously, he removed that from the build.

In the first case previously simply modifies removed while in the second
case previously modifies the entire fragment and thus acts as a transition
word. In the second case you want the comma in the first you do not. In
most cases a leading previously will be of the second form and so wants the
comma.

As an aside the original wording of the above example would imply that a
non-empty array was returned since a "previously empty array" is one that
now has content.​

> FYI, the most frequently updated doc build is here:
>
> http://momjian.us/pgsql_docs/release-9-4.html
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + Everyone has their own god. +
>

​David J.​

On Mon, May 19, 2014 at 12:36 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Thu, May 15, 2014 at 06:08:47PM -0700, David G Johnston wrote:
> > Some errors and suggestions - my apologizes for the format as I do not
> have
> > a proper patching routine setup.
> >
> > Patch Review - Top to Bottom (mostly, I think...)
>
> I have made your suggested adjustments in the attached applied patch.
>
> > Add ROWS FROM() syntax to allow horizontal concatenation of set-returning
> > functions in the FROM-clause (Andrew Gierth)
> > -> Maybe a note about using this to avoid least-common-multiple
> expansion?
>
> Sorry, I do not understand this.
>
>
Apparently, neither do I. I think I was confusing this with set-returning
functions in the select-list. In the from-clause comma-separated functions
are combined using a cross-join, not LCM-expansion.

--
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + Everyone has their own god. +
>

​David J.​

On Mon, May 19, 2014 at 11:30:48AM -0400, David Johnston wrote:
> On Mon, May 19, 2014 at 10:23 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> On Thu, May 15, 2014 at 06:08:47PM -0700, David G Johnston wrote:
> > Some errors and suggestions - my apologizes for the format as I do not
> have
> > a proper patching routine setup.
> >
>
> Sorry, let me address some items I skipped on your list:
>
> > IIUC: Logical decoding allows for streaming of statement-scoped database
> > changes.
>
> I think Logical decoding does more than statement-scoped database
> changes, e.g. it can enable multi-master without triggers.  I am
> hesitant to mention specific items in the release notes for that reason.
>
>
> ​Yeah, probably need to look at this as a bigger unit of work and better
> understand it first.  But 
> "​to be optionally streamed in a configurable format" seems too vague.

Yes, it seems vague to me too, but that's the text the features author
proposed.

> > IIUC: Remove line length restrictions from pgbench.
>
>
> Uh, there is a specific place we removed the ne length restriction in
> pg_bench.
>
>
> ​​I simply interpreted:
>
> ​Allow pgbench to process script files of any line length (Sawada Masahiko)
>
> The previous line limit was BUFSIZ.
> ​
> "script files of any line length" just doesn't sound right to me; and if my
> re-wording is wrong then it also does not actually communicate what was changed
> very well.
>  

Agreed. Here is the new text:

Remove line length limit for <application>pgbench</> scripts

> > style: add comma -> Previously[,] empty arrays were returned (occurs
> > frequently but is minor)
>
> Thanks for the comma adjustments --- I can't decide on that sometimes.
>
>
> ​Not a grammar expert by any means but there are generally two uses of
> "previously".

Thanks for the tips.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

Hi,

I have two comments about 9.4 release notes.

1. typo
>Pg_upgrade now uses -U to specify the user name (Bruce Momjian)

It should be pg_upgrade.

2. undesirable link
>Allow pg_recvlogical to receive data logical decoding data (Andres Freund)

The term of "pg_recvlogical" jumps to a page of pg_receivexlog.
It should jump to pg_recvlogical(app-pgrecvlogical.html).

regards,
--------------------
Tomonari Katsumata

On Fri, May 23, 2014 at 10:11:37AM +0900, Tomonari Katsumata wrote:
> Hi,
>
> I have two comments about 9.4 release notes.
>
> 1. typo
> >Pg_upgrade now uses -U to specify the user name (Bruce Momjian)
>
> It should be pg_upgrade.
>
> 2. undesirable link
> >Allow pg_recvlogical to receive data logical decoding data (Andres Freund)
>
> The term of "pg_recvlogical" jumps to a page of pg_receivexlog.
> It should jump to pg_recvlogical(app-pgrecvlogical.html).

Fixed. Thanks. Uppdated documentation changes can be viewed in five
minutes at:

http://momjian.us/pgsql_docs/release-9-4.html

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Sun, May 4, 2014 at 5:46 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Feedback expected and welcomed.

One item currently reads "Improve valgrind error reporting". I
suggest this be changed to "Add support for Valgrind memcheck memory
error detector". It was possible to use the tool before, but the lack
of cooperation from Postgres made this far less useful.

--
Peter Geoghegan

I propose the attached, miscellaneous edits.

The limit on tuplesort.c internal sort size is a limit on the number of
tuples, not on memory usage. Specifically, the cap increased from 44739242
tuples to 2147483647 tuples. I didn't include those numbers, though.

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

On Tue, Jun 3, 2014 at 01:21:51AM -0700, Peter Geoghegan wrote:
> On Sun, May 4, 2014 at 5:46 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Feedback expected and welcomed.
>
> One item currently reads "Improve valgrind error reporting". I
> suggest this be changed to "Add support for Valgrind memcheck memory
> error detector". It was possible to use the tool before, but the lack
> of cooperation from Postgres made this far less useful.

I have applied the attached patch to improve this. I didn't use "memory
error" because it is not checking for errors in the memory, but rather
invalid memory usage.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +