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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 (Álvaro Herrera)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ During immediate shutdown, send uncatchable termination signals to child processes that have not already shutdown (MauMau,
+ Á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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 -
/messages/by-id/53304439.8000602@dunslane.net
Oleg
On Sun, May 4, 2014 at 4:46 PM, Bruce Momjian <bruce@momjian.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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, May 4, 2014 at 4:06 PM, Oleg Bartunov <obartunov@gmail.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 -
/messages/by-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@hagander.net> wrote:
On Sun, May 4, 2014 at 4:06 PM, Oleg Bartunov <obartunov@gmail.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 -
/messages/by-id/53304439.8000602@dunslane.netAexanders 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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 (Álvaro Herrera) + </para> + </listitem> + + <listitem> + <para> + During immediate shutdown, send uncatchable termination signals to child processes that have not already shutdown (MauMau, + Á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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 -
/messages/by-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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
/messages/by-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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 LinuxPlease see
/messages/by-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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WMb0cfbd10387158ec742f1297704c014aa52e884d96e6707e3b8cce8eb3a992abdb9508b470176e3a6a2b50da104d2162@asav-2.01.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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 5, 2014 at 8:28 AM, Andrew Dunstan <andrew@dunslane.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@dunslane.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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WM688a9252947920da59b7354083b1917d893da6247f83b971c1850df71fd31b1b82d2b8c91083d85527852426d6d6de9e@asav-3.01.com
On Mon, May 5, 2014 at 11:31 AM, Bruce Momjian <bruce@momjian.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 5, 2014 at 1:13 PM, Andrew Dunstan <andrew@dunslane.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, May 4, 2014 at 6:49 AM, Andres Freund <andres@2ndquadrant.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@2ndquadrant.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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@dunslane.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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 5, 2014 at 4:14 PM, Bruce Momjian <bruce@momjian.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 5, 2014 at 4:16 PM, Bruce Momjian <bruce@momjian.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@dunslane.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 5, 2014 at 4:26 PM, Andrew Dunstan <andrew@dunslane.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/05/2014 07:34 PM, Peter Geoghegan wrote:
On Mon, May 5, 2014 at 4:26 PM, Andrew Dunstan <andrew@dunslane.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 5, 2014 at 5:13 PM, Bruce Momjian <bruce@momjian.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:
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.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: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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2014-05-05 Bruce Momjian <bruce@momjian.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?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
From: "Bruce Momjian" <bruce@momjian.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, May 8, 2014 at 10:50 AM, MauMau <maumau307@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, May 9, 2014 at 2:50 AM, MauMau <maumau307@gmail.com> wrote:
From: "Bruce Momjian" <bruce@momjian.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.
+1. Thanks for pointing that out as well!
--
Michael--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
Attachments:
0001-Release-note-improvements.patchtext/x-patch; charset=us-asciiDownload
>From a0359bf8f1f0231f314a6deb537eb7d58075c03c Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Fri, 9 May 2014 16:48:42 +0200
Subject: [PATCH] Release note improvements.
---
doc/src/sgml/release-9.4.sgml | 178 +++++++++++++++++++++---------------------
1 file changed, 88 insertions(+), 90 deletions(-)
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
index 21c6fc7..03bbb12 100644
--- a/doc/src/sgml/release-9.4.sgml
+++ b/doc/src/sgml/release-9.4.sgml
@@ -29,8 +29,8 @@
<listitem>
<para>
- Logical change-set extraction allows database
- changes to be optionally recorded in <emphasis>logical</> format
+ <link linkend='logicaldecoding'>Logical decoding</link> allows database
+ changes to be streamed out in customizable format.
</para>
</listitem>
@@ -263,6 +263,15 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ The maximum number <link linkend="bgworker">background workers</link>
+ that can be registered
+ with <function>RegisterBackgroundWorker()</function> is now limited by
+ <link linkend="guc-max-worker-processes"><varname>max_worker_processes</></link>
+ </para>
+ </listitem>
+
</itemizedlist>
</sect2>
@@ -452,15 +461,15 @@
<listitem>
<para>
- <link linkend="vacuum-for-wraparound">Freeze</link>
- tuples when tables are written with <link
+ Attempt to <link linkend="vacuum-for-wraparound">freeze</link>
+ tuples when tables are rewritten with <link
linkend="SQL-CLUSTER"><command>CLUSTER</></link> or <link
linkend="SQL-VACUUM"><command>VACUUM FULL</></link> (Robert Haas,
Andres Freund)
</para>
<para>
- This avoids the need to freeze the tuples in the future.
+ This can avoid the need to freeze the tuples in the future.
</para>
</listitem>
@@ -545,12 +554,9 @@
<listitem>
<para>
- Add <structname>xid</> and <link
- linkend="ddl-system-columns"><structname>xmin</></link>
- to system views <link
- linkend="pg-stat-activity-view"><structname>pg_stat_activity</></link>
- and <link
- linkend="pg-stat-replication-view"><structname>pg_stat_replication</></link>
+ Add <varname>backend_xid</> and <varname>backend_xmin</> columns to
+ the system view <link linkend="pg-stat-activity-view"><structname>pg_stat_activity</></link>
+ and <varname>backend_xmin</> to <link linkend="pg-stat-replication-view"><structname>pg_stat_replication</></link>
(Christian Kruse)
</para>
</listitem>
@@ -571,10 +577,10 @@
</para>
<para>
- Such keys are faster and have improved security
- over previous options. New variable <link
- linkend="guc-ssl-ecdh-curve"><varname>ssl_ecdh_curve</></link>
- controls the curve that is used.
+ Such keys are faster and have improved security over previous
+ options. The new configuration
+ parameter <link linkend="guc-ssl-ecdh-curve"><varname>ssl_ecdh_curve</></link>
+ controls which curve is used.
</para>
</listitem>
@@ -617,15 +623,14 @@
<listitem>
<para>
- Add <acronym>SQL</>-level command <link
+ Add <acronym>SQL</>-level <link
linkend="SQL-ALTERSYSTEM"><command>ALTER SYSTEM</></link> command
- to edit the <filename>postgresql.conf</> configuration file
- (Amit Kapila)
+ to adjust server-wide settings (Amit Kapila)
</para>
<para>
- Previously <filename>postgresql.conf</> could only be edited at
- the file system level.
+ Previously such settings could only be changed by
+ editing <filename>postgresql.conf</> at the file system level.
</para>
</listitem>
@@ -680,8 +685,8 @@
</para>
<para>
- Hint bits are not normally logged, except when checksums are
- enabled. This is useful for tools like <application>pg_rewind</>.
+ Hint bits are not normally logged, except when checksums are enabled.
+ This is useful for external tools like <application>pg_rewind</>.
</para>
</listitem>
@@ -702,9 +707,10 @@
</para>
<para>
- Such libraries are auto-<link
- linkend="SQL-LOAD"><command>LOAD</></link>'ed, unlike <link
- linkend="guc-local-preload-libraries"><varname>local_preload_libraries</></link>.
+ In contrast
+ to <link linkend="guc-local-preload-libraries"><varname>local_preload_libraries</></link>
+ this parameter can load all shared libraries, not just ones in
+ the <literal>$libdir/plugins/</literal>.
</para>
</listitem>
@@ -775,28 +781,25 @@
<listitem>
<para>
- Allow <link
- linkend="recovery-config"><filename>recovery.conf</></link>
- parameter <link
- linkend="min-recovery-apply-delay"><varname>min_recovery_apply_delay</></link>
- to force delayed replication (Robert Haas, Fabrízio de
- Royes Mello, Simon Riggs)
+ Add <link linkend="recovery-config"><filename>recovery.conf</></link>
+ parameter <link linkend="min-recovery-apply-delay"><varname>min_recovery_apply_delay</></link>
+ to delay replication (Robert Haas, Fabrízio de Royes Mello,
+ Simon Riggs)
</para>
<para>
- This is useful for delaying replaying of user errors on standby
+ This is useful for delaying replaying of user errors to standby
servers.
</para>
</listitem>
<listitem>
<para>
- Add <link
+ Add new <link
linkend="recovery-target"><varname>recovery_target</></link>
- option <option>immediate</> option to replay
- <link linkend="wal"><acronym>WAL</></link> stop
- recovery when a consistent state is reached, i.e. <link
- linkend="functions-admin-backup-table"><function>pg_stop_backup()</></link>
+ parameter which can be set to <option>immediate</> to stop
+ <link linkend="wal"><acronym>WAL</></link>
+ recovery as soon as a consistent state is reached
(MauMau, Heikki Linnakangas)
</para>
</listitem>
@@ -807,11 +810,11 @@
</para>
<para>
- The timestamp reported by <link
- linkend="functions-recovery-info-table"><function>pg_last_xact_replay_timestamp()</></link>
- now shows information about committed records, not commits being
- replayed. Recovering to restore points now replay the restore
- point, rather than stop just before the restore point.
+ The timestamp reported
+ by <link linkend="functions-recovery-info-table"><function>pg_last_xact_replay_timestamp()</></link>
+ now shows information about already committed records, not of commits
+ about to be committed. Recovering to restore points now replay the
+ restore point, rather than stop just before the restore point.
</para>
</listitem>
@@ -831,13 +834,13 @@
<listitem>
<para>
Add <link linkend="streaming-replication-slots">replication
- slots</link> to report the <acronym>WAL</> activity on streaming
- standbys (Andres Freund, Robert Haas)
+ slots</link> to coordinate activity on streaming standbys with the
+ node they are streaming from (Andres Freund, Robert Haas)
</para>
<para>
Replication slots allow preservation of resources like
- <acronym>WAL</> files on the primary that are needed by standby
+ <acronym>WAL</> files and on the primary that are needed by standby
servers.
</para>
</listitem>
@@ -872,19 +875,18 @@
</itemizedlist>
<sect4>
- <title><link linkend="logicaldecoding">Logical Change-Set Extraction</></title>
+ <title><link linkend="logicaldecoding">Logical Decoding</></title>
<para>
- Logical change-set extraction allows database
- changes to be optionally recorded in <emphasis>logical</> format
- in the <link linkend="wal"><acronym>WAL</></link>. This format can
- be easily processed by external tools. In previous releases, only
- binary changes were recorded in the <acronym>WAL</>. To implement
- this feature, the following changes were made:
+ Logical decoding allows database changes to be optionally streamed in a
+ configurable format. The data is read from
+ the <link linkend="wal"><acronym>WAL</></link> and transformed into the
+ desired target format. To implement this feature, the following changes
+ were made:
</para>
<itemizedlist>
-
+ <!-- FIXME: This imo needs a pretty fundamental rewrite -->
<listitem>
<para>
Add new <option>logical</> <link
@@ -953,15 +955,15 @@
<listitem>
<para>
Add <link linkend="queries-tablefunctions"><literal>ROWS
- FROM</></link> syntax to allow horizontal concatenation of
- <literal>FROM</>-clause set-returning functions (Andrew Gierth)
+ FROM()</></link> syntax to allow horizontal concatenation of
+ set-returning functions in the <literal>FROM</>-clause (Andrew Gierth)
</para>
</listitem>
<listitem>
<para>
Add <link linkend="queries-tablefunctions"><literal>WITH
- ORDINALITY</></link> which numbers rows returned from
+ ORDINALITY</></link> syntax which numbers rows returned from
<literal>FROM</>-clause functions (Andrew Gierth, David Fetter)
</para>
@@ -978,8 +980,9 @@
</para>
<para>
- This was added for consistency, and so querying tables with no
- columns would not produce an error.
+ <!-- FIXME: drop? -->
+ This was added so views that select from a column with zero columns
+ can be dumped correctly.
</para>
</listitem>
@@ -1000,14 +1003,16 @@
</para>
<para>
+ <!-- FIXME: compatibility break entry? -->
<command>DISCARD ALL</> will now also discard such information.
</para>
</listitem>
<listitem>
<para>
- Allow quoted strings matching the null string to be converted
- to NULL in <link linkend="SQL-COPY"><command>COPY FROM</></link>
+ Add <command>FORCE NULL</> option
+ to <link linkend="SQL-COPY"><command>COPY FROM</></link> which causes
+ quoted strings matching the null string to be converted to NULL in
in <literal>CSV</> mode (Ian Barwick, Michael Paquier)
</para>
@@ -1019,14 +1024,13 @@
<listitem>
<para>
- Issue warnings for <link linkend="SQL-SET"><command>SET</></link>
- outside of a transaction block, as they have no effect (Bruce
- Momjian)
+ Issue warnings for commands used outside of transactions when they have have no
+ effect there (Bruce Momjian)
</para>
<para>
The cases are <literal>SET
- LOCAL</>/<literal>CONSTRAINTS</>/<literal>TRANSACTION</> and
+ LOCAL</>, <literal>SET CONSTRAINTS</>, <literal>SET TRANSACTION</> and
<literal>ABORT</>.
</para>
</listitem>
@@ -1083,9 +1087,9 @@
<listitem>
<para>
- Allow <link linkend="SQL-CREATEVIEW-updatable-views">auto-updates
- on views</link> where only some columns are auto-updateable
- (Dean Rasheed)
+ Allow updating <link linkend="SQL-CREATEVIEW-updatable-views">updatable
+ views</link> where only some columns are auto-updateable (Dean
+ Rasheed)
</para>
<para>
@@ -1148,7 +1152,7 @@
<para>
Previously, relations moved into the system catalog schema could
- not be modified.
+ not be modified or dropped anymore.
</para>
</listitem>
@@ -1204,7 +1208,8 @@
ON</>, <literal>SET WITHOUT CLUSTER</>, <literal>ALTER COLUMN
SET STATISTICS</>, <literal>ALTER COLUMN</> <literal>SET</>
<option>(attribute_option)</>, <literal>ALTER COLUMN RESET</>
- <option>(attribute_option)</>.
+ <option>(attribute_option)</> don't require access exclusive locks
+ anymore.
</para>
</listitem>
@@ -1225,12 +1230,6 @@
linkend="datatype-line"><type>line</></link> data type (Peter
Eisentraut)
</para>
-
- <para>
- The line <emphasis>segment</> data type (<link
- linkend="datatype-lseg"><type>LSEG</></link>) has always been
- fully supported.
- </para>
</listitem>
<listitem>
@@ -1331,10 +1330,6 @@
and <function>pg_sleep_until(timestamp)</> to specify sophisticated
delays (Vik Fearing, Julien Rouhaud)
</para>
-
- <para>
- <function>pg_sleep()</> only supports delays specified in seconds.
- </para>
</listitem>
<listitem>
@@ -1375,8 +1370,8 @@
</para>
<para>
- The functions being with <literal>make_</>, e.g. <link
- linkend="functions-datetime-table"><function>make_date()</></link>.
+ These functions are name <literal>make_<replacable>type</></>,
+ e.g. <link linkend="functions-datetime-table"><function>make_date()</></link>.
</para>
</listitem>
@@ -1419,17 +1414,18 @@
<listitem>
<para>
- Add functions for error-free <structname>pg_class</>,
+ Add functions for lookups of objects in <structname>pg_class</>,
<structname>pg_proc</>, <structname>pg_type</>, and
- <structname>pg_operator</> lookups (Yugo Nagata, Nozomi Anzai,
- Robert Haas)
+ <structname>pg_operator</> that don not error out if the the searched
+ for object does not exist but return NULL instead (Yugo Nagata, Nozomi
+ Anzai, Robert Haas)
</para>
<para>
For example, <link
linkend="functions-info-catalog-table"><function>to_regclass()</></link>
- does error-free lookups of <structname>pg_class</>, and returns
- NULL for lookup failures.
+ does lookups in <structname>pg_class</>, and returns NULL when the
+ searched for relation does not exist.
</para>
</listitem>
@@ -1437,7 +1433,7 @@
<para>
Add function <link
linkend="functions-admin-dblocation"><function>pg_filenode_relation()</></link>
- to allow for more efficient filenode to relation lookups (Andres
+ to allow for more efficient filenode to relation lookups (Andres
Freund)
</para>
</listitem>
@@ -1508,6 +1504,7 @@
</listitem>
<listitem>
+ <!-- FIXME -->
<para>
Allow polymorphic aggregates to have non-polymorphic state data
types ? (Tom Lane)
@@ -1594,6 +1591,7 @@
(Rodolfo Campero)
</para>
+ <!-- FIXME: mention in compatibility section -->
<para>
Previously they were treated as strings.
</para>
@@ -1675,9 +1673,9 @@
<listitem>
<para>
- Allow <link linkend="APP-VACUUMDB"><application>vacuumdb</></link>
- <option>--analyze-in-stages</> to analyze in stages of increasing
- granularity (Peter Eisentraut)
+ Add <link linkend="APP-VACUUMDB"><application>vacuumdb</></link>
+ option <option>--analyze-in-stages</> to analyze in stages of
+ increasing granularity (Peter Eisentraut)
</para>
<para>
--
2.0.0.rc2.4.g1dc51c6.dirty
On Tue, May 6, 2014 at 03:53:54PM +0200, Nicolas Barbier wrote:
2014-05-05 Bruce Momjian <bruce@momjian.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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 FunctionsAdd 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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, May 9, 2014 at 02:50:05AM +0900, MauMau wrote:
From: "Bruce Momjian" <bruce@momjian.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.
Agreed, added:
Allow client-only installs for <acronym>MSVC</>
(Windows) builds (MauMau)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
Attachments:
rel.difftext/x-diff; charset=us-asciiDownload
commit 062f53518927f9bfe1820578ce79d3180b1aa2ca
Author: Bruce Momjian <bruce@momjian.us>
Date: Tue May 13 15:12:54 2014 -0400
docs: 9.4 release notes adjustments
Patch by Andres Freund, slight adjustments by me
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
new file mode 100644
index e537a1f..cabfbdd
*** a/doc/src/sgml/release-9.4.sgml
--- b/doc/src/sgml/release-9.4.sgml
***************
*** 29,36 ****
<listitem>
<para>
! Logical change-set extraction allows database
! changes to be optionally recorded in <emphasis>logical</> format
</para>
</listitem>
--- 29,36 ----
<listitem>
<para>
! <link linkend="logicaldecoding">Logical decoding</link> allows database
! changes to be streamed out in customizable format
</para>
</listitem>
***************
*** 223,228 ****
--- 223,239 ----
<listitem>
<para>
+ Handle domains over arrays like plain arrays in PL/Python
+ (Rodolfo Campero)
+ </para>
+
+ <para>
+ Previously they were treated as strings.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
Have libpq's <link
linkend="libpq-pqconnectdbparams"><function>PQconnectdbParams()</></link>
and <link
***************
*** 263,268 ****
--- 274,288 ----
</para>
</listitem>
+ <listitem>
+ <para>
+ The maximum number of <link linkend="bgworker">background workers</link>
+ that can be registered
+ by <function>RegisterBackgroundWorker()</function> is now limited to
+ <link linkend="guc-max-worker-processes"><varname>max_worker_processes</></link>
+ </para>
+ </listitem>
+
</itemizedlist>
</sect2>
***************
*** 452,466 ****
<listitem>
<para>
! <link linkend="vacuum-for-wraparound">Freeze</link>
! tuples when tables are written with <link
linkend="SQL-CLUSTER"><command>CLUSTER</></link> or <link
linkend="SQL-VACUUM"><command>VACUUM FULL</></link> (Robert Haas,
Andres Freund)
</para>
<para>
! This avoids the need to freeze the tuples in the future.
</para>
</listitem>
--- 472,486 ----
<listitem>
<para>
! Attempt to <link linkend="vacuum-for-wraparound">freeze</link>
! tuples when tables are rewritten with <link
linkend="SQL-CLUSTER"><command>CLUSTER</></link> or <link
linkend="SQL-VACUUM"><command>VACUUM FULL</></link> (Robert Haas,
Andres Freund)
</para>
<para>
! This can avoid the need to freeze the tuples in the future.
</para>
</listitem>
***************
*** 545,556 ****
<listitem>
<para>
! Add <structfield>xid</> and <link
! linkend="ddl-system-columns"><structfield>xmin</></link>
! to system views <link
! linkend="pg-stat-activity-view"><structname>pg_stat_activity</></link>
! and <link
! linkend="pg-stat-replication-view"><structname>pg_stat_replication</></link>
(Christian Kruse)
</para>
</listitem>
--- 565,573 ----
<listitem>
<para>
! Add <varname>backend_xid</> and <varname>backend_xmin</> columns to
! the system view <link linkend="pg-stat-activity-view"><structname>pg_stat_activity</></link>
! and <varname>backend_xmin</> to <link linkend="pg-stat-replication-view"><structname>pg_stat_replication</></link>
(Christian Kruse)
</para>
</listitem>
***************
*** 571,580 ****
</para>
<para>
! Such keys are faster and have improved security
! over previous options. New variable <link
! linkend="guc-ssl-ecdh-curve"><varname>ssl_ecdh_curve</></link>
! controls the curve that is used.
</para>
</listitem>
--- 588,597 ----
</para>
<para>
! Such keys are faster and have improved security over previous
! options. The new configuration
! parameter <link linkend="guc-ssl-ecdh-curve"><varname>ssl_ecdh_curve</></link>
! controls which curve is used.
</para>
</listitem>
***************
*** 617,631 ****
<listitem>
<para>
! Add <acronym>SQL</>-level command <link
linkend="SQL-ALTERSYSTEM"><command>ALTER SYSTEM</></link> command
! to edit the <filename>postgresql.conf</> configuration file
! (Amit Kapila)
</para>
<para>
! Previously <filename>postgresql.conf</> could only be edited at
! the file system level.
</para>
</listitem>
--- 634,647 ----
<listitem>
<para>
! Add <acronym>SQL</>-level <link
linkend="SQL-ALTERSYSTEM"><command>ALTER SYSTEM</></link> command
! to adjust server-wide settings (Amit Kapila)
</para>
<para>
! Previously such settings could only be changed by
! editing <filename>postgresql.conf</> at the file system level.
</para>
</listitem>
***************
*** 680,687 ****
</para>
<para>
! Hint bits are not normally logged, except when checksums are
! enabled. This is useful for tools like <application>pg_rewind</>.
</para>
</listitem>
--- 696,703 ----
</para>
<para>
! Hint bits are not normally logged, except when checksums are enabled.
! This is useful for external tools like <application>pg_rewind</>.
</para>
</listitem>
***************
*** 702,710 ****
</para>
<para>
! Such libraries are auto-<link
! linkend="SQL-LOAD"><command>LOAD</></link>'ed, unlike <link
! linkend="guc-local-preload-libraries"><varname>local_preload_libraries</></link>.
</para>
</listitem>
--- 718,727 ----
</para>
<para>
! In contrast
! to <link linkend="guc-local-preload-libraries"><varname>local_preload_libraries</></link>,
! this parameter can load any shared library, not just those in
! the <filename>$libdir/plugins</> directory.
</para>
</listitem>
***************
*** 775,790 ****
<listitem>
<para>
! Add <link
! linkend="recovery-config"><filename>recovery.conf</></link>
! parameter <link
! linkend="recovery-min-apply-delay"><varname>recovery_min_apply_delay</></link>
! to force delayed replication (Robert Haas, Fabrízio de
! Royes Mello, Simon Riggs)
</para>
<para>
! This is useful for delaying replaying of user errors on standby
servers.
</para>
</listitem>
--- 792,805 ----
<listitem>
<para>
! Add <link linkend="recovery-config"><filename>recovery.conf</></link>
! parameter <link linkend="recovery-min-apply-delay"><varname>recovery_min_apply_delay</></link>
! to delay replication (Robert Haas, Fabrízio de Royes Mello,
! Simon Riggs)
</para>
<para>
! This is useful for delaying the replay of user errors on standby
servers.
</para>
</listitem>
***************
*** 793,803 ****
<para>
Add <link
linkend="recovery-target"><varname>recovery_target</></link>
! option <option>immediate</> option to replay
! <link linkend="wal"><acronym>WAL</></link> stop
! recovery when a consistent state is reached, i.e. <link
! linkend="functions-admin-backup-table"><function>pg_stop_backup()</></link>
! (MauMau, Heikki Linnakangas)
</para>
</listitem>
--- 808,816 ----
<para>
Add <link
linkend="recovery-target"><varname>recovery_target</></link>
! option <option>immediate</> to stop <link
! linkend="wal"><acronym>WAL</></link> recovery as soon as a
! consistent state is reached (MauMau, Heikki Linnakangas)
</para>
</listitem>
***************
*** 807,817 ****
</para>
<para>
! The timestamp reported by <link
! linkend="functions-recovery-info-table"><function>pg_last_xact_replay_timestamp()</></link>
! now shows information about committed records, not commits being
! replayed. Recovering to restore points now replay the restore
! point, rather than stop just before the restore point.
</para>
</listitem>
--- 820,830 ----
</para>
<para>
! The timestamp reported
! by <link linkend="functions-recovery-info-table"><function>pg_last_xact_replay_timestamp()</></link>
! now shows information about already-committed records, not of transactions
! about to be committed. Recovering to a restore point now replays the
! restore point, rather than stopping just before the restore point.
</para>
</listitem>
***************
*** 831,838 ****
<listitem>
<para>
Add <link linkend="streaming-replication-slots">replication
! slots</link> to report the <acronym>WAL</> activity on streaming
! standbys (Andres Freund, Robert Haas)
</para>
<para>
--- 844,851 ----
<listitem>
<para>
Add <link linkend="streaming-replication-slots">replication
! slots</link> to coordinate activity on streaming standbys with the
! node they are streaming from (Andres Freund, Robert Haas)
</para>
<para>
***************
*** 872,890 ****
</itemizedlist>
<sect4>
! <title><link linkend="logicaldecoding">Logical Change-Set Extraction</></title>
<para>
! Logical change-set extraction allows database
! changes to be optionally recorded in <emphasis>logical</> format
! in the <link linkend="wal"><acronym>WAL</></link>. This format can
! be easily processed by external tools. In previous releases, only
! binary changes were recorded in the <acronym>WAL</>. To implement
! this feature, the following changes were made:
</para>
<itemizedlist>
!
<listitem>
<para>
Add new <option>logical</> <link
--- 885,902 ----
</itemizedlist>
<sect4>
! <title><link linkend="logicaldecoding">Logical Decoding</></title>
<para>
! Logical decoding allows database changes to be optionally streamed in a
! configurable format. The data is read from
! the <link linkend="wal"><acronym>WAL</></link> and transformed into the
! desired target format. To implement this feature, the following changes
! were made:
</para>
<itemizedlist>
! <!-- FIXME: This imo needs a pretty fundamental rewrite -->
<listitem>
<para>
Add new <option>logical</> <link
***************
*** 953,967 ****
<listitem>
<para>
Add <link linkend="queries-tablefunctions"><literal>ROWS
! FROM</></link> syntax to allow horizontal concatenation of
! <literal>FROM</>-clause set-returning functions (Andrew Gierth)
</para>
</listitem>
<listitem>
<para>
Add <link linkend="queries-tablefunctions"><literal>WITH
! ORDINALITY</></link> which numbers rows returned from
<literal>FROM</>-clause functions (Andrew Gierth, David Fetter)
</para>
--- 965,979 ----
<listitem>
<para>
Add <link linkend="queries-tablefunctions"><literal>ROWS
! FROM()</></link> syntax to allow horizontal concatenation of
! set-returning functions in the <literal>FROM</>-clause (Andrew Gierth)
</para>
</listitem>
<listitem>
<para>
Add <link linkend="queries-tablefunctions"><literal>WITH
! ORDINALITY</></link> syntax which numbers rows returned from
<literal>FROM</>-clause functions (Andrew Gierth, David Fetter)
</para>
***************
*** 978,985 ****
</para>
<para>
! This was added for consistency, and so querying tables with no
! columns would not produce an error.
</para>
</listitem>
--- 990,998 ----
</para>
<para>
! <!-- FIXME: drop? -->
! This was added so views that select from a table with zero columns
! can be dumped correctly.
</para>
</listitem>
***************
*** 1000,1013 ****
</para>
<para>
<command>DISCARD ALL</> will now also discard such information.
</para>
</listitem>
<listitem>
<para>
! Allow quoted strings matching the null string to be converted
! to NULL in <link linkend="SQL-COPY"><command>COPY FROM</></link>
in <literal>CSV</> mode (Ian Barwick, Michael Paquier)
</para>
--- 1013,1028 ----
</para>
<para>
+ <!-- FIXME: compatibility break entry? -->
<command>DISCARD ALL</> will now also discard such information.
</para>
</listitem>
<listitem>
<para>
! Add <command>FORCE NULL</> option
! to <link linkend="SQL-COPY"><command>COPY FROM</></link> which causes
! quoted strings matching the null string to be converted to NULL in
in <literal>CSV</> mode (Ian Barwick, Michael Paquier)
</para>
***************
*** 1019,1032 ****
<listitem>
<para>
! Issue warnings for <link linkend="SQL-SET"><command>SET</></link>
! outside of a transaction block, as they have no effect (Bruce
! Momjian)
</para>
<para>
The cases are <literal>SET
! LOCAL</>/<literal>CONSTRAINTS</>/<literal>TRANSACTION</> and
<literal>ABORT</>.
</para>
</listitem>
--- 1034,1046 ----
<listitem>
<para>
! Issue warnings for commands used outside of transaction blocks
! because they have no effect (Bruce Momjian)
</para>
<para>
The cases are <literal>SET
! LOCAL</>, <literal>SET CONSTRAINTS</>, <literal>SET TRANSACTION</> and
<literal>ABORT</>.
</para>
</listitem>
***************
*** 1083,1091 ****
<listitem>
<para>
! Allow <link linkend="SQL-CREATEVIEW-updatable-views">auto-updates
! on views</link> where only some columns are auto-updateable
! (Dean Rasheed)
</para>
<para>
--- 1097,1105 ----
<listitem>
<para>
! Allow the updating of <link
! linkend="SQL-CREATEVIEW-updatable-views">views</link>
! where only some columns are auto-updateable (Dean Rasheed)
</para>
<para>
***************
*** 1147,1154 ****
</para>
<para>
! Previously, relations moved into the system catalog schema could
! not be modified.
</para>
</listitem>
--- 1161,1168 ----
</para>
<para>
! Previously, relations once moved into the system catalog schema could
! no longer be modified or dropped.
</para>
</listitem>
***************
*** 1204,1210 ****
ON</>, <literal>SET WITHOUT CLUSTER</>, <literal>ALTER COLUMN
SET STATISTICS</>, <literal>ALTER COLUMN</> <literal>SET</>
<option>(attribute_option)</>, <literal>ALTER COLUMN RESET</>
! <option>(attribute_option)</>.
</para>
</listitem>
--- 1218,1225 ----
ON</>, <literal>SET WITHOUT CLUSTER</>, <literal>ALTER COLUMN
SET STATISTICS</>, <literal>ALTER COLUMN</> <literal>SET</>
<option>(attribute_option)</>, <literal>ALTER COLUMN RESET</>
! <option>(attribute_option)</> no longer require <literal>ACCESS
! EXCLUSIVE</> locks.
</para>
</listitem>
***************
*** 1375,1382 ****
</para>
<para>
! The functions being with <literal>make_</>, e.g. <link
! linkend="functions-datetime-table"><function>make_date()</></link>.
</para>
</listitem>
--- 1390,1397 ----
</para>
<para>
! These functions are prefixed with <literal>make_</>,
! e.g. <link linkend="functions-datetime-table"><function>make_date()</></link>.
</para>
</listitem>
***************
*** 1419,1427 ****
<listitem>
<para>
! 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)
</para>
--- 1434,1442 ----
<listitem>
<para>
! Add functions for looking up objects in <structname>pg_class</>,
<structname>pg_proc</>, <structname>pg_type</>, and
! <structname>pg_operator</> which do not generate errors for
non-existent objects (Yugo Nagata, Nozomi Anzai,
Robert Haas)
</para>
***************
*** 1429,1436 ****
<para>
For example, <link
linkend="functions-info-catalog-table"><function>to_regclass()</></link>
! does error-free lookups of <structname>pg_class</>, and returns
! NULL for lookup failures.
</para>
</listitem>
--- 1444,1451 ----
<para>
For example, <link
linkend="functions-info-catalog-table"><function>to_regclass()</></link>
! does lookups of <structname>pg_class</> and returns NULL for
! non-existent objects.
</para>
</listitem>
***************
*** 1438,1444 ****
<para>
Add function <link
linkend="functions-admin-dblocation"><function>pg_filenode_relation()</></link>
! to allow for more efficient filenode to relation lookups (Andres
Freund)
</para>
</listitem>
--- 1453,1459 ----
<para>
Add function <link
linkend="functions-admin-dblocation"><function>pg_filenode_relation()</></link>
! to allow for more efficient filenode to relation lookups (Andres
Freund)
</para>
</listitem>
***************
*** 1509,1514 ****
--- 1524,1530 ----
</listitem>
<listitem>
+ <!-- FIXME -->
<para>
Allow polymorphic aggregates to have non-polymorphic state data
types ? (Tom Lane)
***************
*** 1591,1607 ****
<listitem>
<para>
- Handle domains over arrays like plain arrays in PL/Python
- (Rodolfo Campero)
- </para>
-
- <para>
- Previously they were treated as strings.
- </para>
- </listitem>
-
- <listitem>
- <para>
Convert <link linkend="datatype-numeric"><type>NUMERIC</></link>s
to <type>decimal</> values in PL/Python (Szymon Guz, Ronan Dunklau)
</para>
--- 1607,1612 ----
***************
*** 1676,1684 ****
<listitem>
<para>
! Allow <link linkend="APP-VACUUMDB"><application>vacuumdb</></link>
! <option>--analyze-in-stages</> to analyze in stages of increasing
! granularity (Peter Eisentraut)
</para>
<para>
--- 1681,1689 ----
<listitem>
<para>
! Add <link linkend="APP-VACUUMDB"><application>vacuumdb</></link>
! option <option>--analyze-in-stages</> to analyze in stages of
! increasing granularity (Peter Eisentraut)
</para>
<para>
On 4 May 2014 13:46, Bruce Momjian <bruce@momjian.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 14, 2014 at 08:33:15AM +0100, Dean Rasheed wrote:
On 4 May 2014 13:46, Bruce Momjian <bruce@momjian.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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
Attachments:
rel.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
new file mode 100644
index cabfbdd..eb0b4f8
*** a/doc/src/sgml/release-9.4.sgml
--- b/doc/src/sgml/release-9.4.sgml
***************
*** 1097,1118 ****
<listitem>
<para>
! Allow the updating of <link
! linkend="SQL-CREATEVIEW-updatable-views">views</link>
! where only some columns are auto-updateable (Dean Rasheed)
</para>
<para>
! 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.
</para>
</listitem>
<listitem>
<para>
Allow control over whether <command>INSERT</>s and
! <command>UPDATE</>s can add rows to an auto-updateable view that
would no longer appear in the view (Dean Rasheed)
</para>
--- 1097,1121 ----
<listitem>
<para>
! Allow views to be <link
! linkend="SQL-CREATEVIEW-updatable-views">automatically
! updated<link> even if they contain some non-updatable columns
! (Dean Rasheed)
</para>
<para>
! Previously the presence of non-updatable columns such as
! expressions, literals, and function cals prevented automatic
! updates. Now <command>INSERT</>s, <command>UPDATE</>s and
! <command>DELETE</>s are supported, provided that they do not
! attempt to assign new values to any of the non-updatable columns.
</para>
</listitem>
<listitem>
<para>
Allow control over whether <command>INSERT</>s and
! <command>UPDATE</>s can add rows to an auto-updatable view that
would no longer appear in the view (Dean Rasheed)
</para>
***************
*** 1125,1131 ****
<listitem>
<para>
Allow <link linkend="rules-privileges">security barrier views</>
! to be automatically updateable (Dean Rasheed)
</para>
</listitem>
--- 1128,1134 ----
<listitem>
<para>
Allow <link linkend="rules-privileges">security barrier views</>
! to be automatically updatable (Dean Rasheed)
</para>
</listitem>
On 14 May 2014 15:07, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, May 14, 2014 at 08:33:15AM +0100, Dean Rasheed wrote:
On 4 May 2014 13:46, Bruce Momjian <bruce@momjian.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
Attachments:
0001-Further-9.4-release-notes-improvements.patchtext/x-patch; charset=us-asciiDownload
>From 18511f2e4cd7d72b8d943efd9e6501d3903a64c4 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Fri, 16 May 2014 01:37:07 +0200
Subject: [PATCH] Further 9.4 release notes improvements.
---
doc/src/sgml/release-9.4.sgml | 52 +++++++++++++++++++++++++++----------------
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
index 3070d0b..e143178 100644
--- a/doc/src/sgml/release-9.4.sgml
+++ b/doc/src/sgml/release-9.4.sgml
@@ -30,7 +30,7 @@
<listitem>
<para>
<link linkend="logicaldecoding">Logical decoding</link> allows database
- changes to be streamed out in customizable format
+ changes to be streamed out in a customizable format
</para>
</listitem>
@@ -298,6 +298,12 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ <command>DISCARD ALL</> now also discards the states of sequences.
+ </para>
+ </listitem>
+
</itemizedlist>
</sect2>
@@ -1005,7 +1011,6 @@
</para>
<para>
- <!-- FIXME: drop? -->
This was added so views that select from a table with zero columns
can be dumped correctly.
</para>
@@ -1028,7 +1033,6 @@
</para>
<para>
- <!-- FIXME: compatibility break entry? -->
<command>DISCARD ALL</> will now also discard such information.
</para>
</listitem>
@@ -1199,6 +1203,11 @@
AGGREGATE</></link> to supply the size of the aggregate's
transition state data (Hadi Moshayedi)
</para>
+
+ <para>
+ This allows the plannet to better estimate how much memory will be
+ used when aggregating.
+ </para>
</listitem>
</itemizedlist>
@@ -1218,7 +1227,7 @@
<listitem>
<para>
- Allow the changing of foreign key constraint via <link
+ Allow the changing foreign key constraints's deferrability via <link
linkend="SQL-ALTERTABLE"><command>ALTER TABLE</></link>
... <literal>ALTER CONSTRAINT</> (Simon Riggs)
</para>
@@ -1254,7 +1263,7 @@
<listitem>
<para>
- Fully-implement the <link
+ Fully implement the <link
linkend="datatype-line"><type>line</></link> data type (Peter
Eisentraut)
</para>
@@ -1472,7 +1481,7 @@
<para>
Add function <link
linkend="functions-admin-dblocation"><function>pg_filenode_relation()</></link>
- to allow for more efficient filenode to relation lookups (Andres
+ to allow for more efficient lookups from filenode to relation (Andres
Freund)
</para>
</listitem>
@@ -1543,10 +1552,13 @@
</listitem>
<listitem>
- <!-- FIXME -->
<para>
Allow polymorphic aggregates to have non-polymorphic state data
- types ? (Tom Lane)
+ types (Tom Lane)
+ </para>
+ <para>
+ This allows to declare aggregates like the builtin
+ <function>array_agg()</> from SQL.
</para>
</listitem>
@@ -1772,8 +1784,8 @@
<listitem>
<para>
- Allow field wrapping to <application>psql</>'s "extended" mode
- (Sergey Muraviov)
+ Add ability to wrap long lines in <application>psql</>'s "expanded"
+ mode by using <command>\pset format wrapped</> (Sergey Muraviov)
</para>
</listitem>
@@ -2218,7 +2230,8 @@
<listitem>
<para>
Add <link linkend="pgprewarm"><application>pg_prewarm</></link>
- to preload relation data into the shared buffer cache (Robert Haas)
+ extension to preload relation data into the shared buffer cache
+ (Robert Haas)
</para>
<para>
@@ -2243,7 +2256,7 @@
<listitem>
<para>
- Add logging of trigger execution to <link
+ Add option to include trigger execution time to <link
linkend="auto-explain"><application>auto_explain</></link>
(Horiguchi Kyotaro)
</para>
@@ -2279,9 +2292,10 @@
<listitem>
<para>
- Improve indexing of <link
- linkend="pgtrgm"><application>pg_trgm</></link> values to
- discourage indexing whitespace (Alexander Korotkov)
+ Improve <link linkend="pgtrgm"><application>pg_trgm</>'s</link>
+ generation of trigrams for indexed regular expression searches by
+ discouraging the use of trigrams containing whitespace (Alexander
+ Korotkov)
</para>
</listitem>
@@ -2328,7 +2342,7 @@
<listitem>
<para>
- Allow pgbench to process script files of any line length (Sawada
+ Allow <application>pgbench</> to process script files of any line length (Sawada
Masahiko)
</para>
@@ -2339,20 +2353,20 @@
<listitem>
<para>
- Add <application>pg_bench</> option (<option>--rate</>) to control
+ Add <application>pgbench</> option (<option>--rate</>) to control
the transaction rate (Fabien Coelho)
</para>
</listitem>
<listitem>
<para>
- Add <option>--progress</> output option to pgbench (Fabien Coelho)
+ Add <option>--progress</> output option to <application>pgbench</> (Fabien Coelho)
</para>
</listitem>
<listitem>
<para>
- Add long options to pgbench (Fabien Coelho)
+ Add long options to <application>pgbench</> (Fabien Coelho)
</para>
</listitem>
--
2.0.0.rc2.4.g1dc51c6.dirty
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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
Attachments:
rel.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
new file mode 100644
index 3070d0b..91a586f
*** a/doc/src/sgml/release-9.4.sgml
--- b/doc/src/sgml/release-9.4.sgml
***************
*** 30,36 ****
<listitem>
<para>
<link linkend="logicaldecoding">Logical decoding</link> allows database
! changes to be streamed out in customizable format
</para>
</listitem>
--- 30,36 ----
<listitem>
<para>
<link linkend="logicaldecoding">Logical decoding</link> allows database
! changes to be streamed out in a customizable format
</para>
</listitem>
***************
*** 298,303 ****
--- 298,309 ----
</para>
</listitem>
+ <listitem>
+ <para>
+ <command>DISCARD ALL</> now also discards the state of sequences.
+ </para>
+ </listitem>
+
</itemizedlist>
</sect2>
***************
*** 1005,1011 ****
</para>
<para>
- <!-- FIXME: drop? -->
This was added so views that select from a table with zero columns
can be dumped correctly.
</para>
--- 1011,1016 ----
***************
*** 1028,1034 ****
</para>
<para>
- <!-- FIXME: compatibility break entry? -->
<command>DISCARD ALL</> will now also discard such information.
</para>
</listitem>
--- 1033,1038 ----
***************
*** 1199,1204 ****
--- 1203,1213 ----
AGGREGATE</></link> to supply the size of the aggregate's
transition state data (Hadi Moshayedi)
</para>
+
+ <para>
+ This allows the optimizer to better estimate how much memory will be
+ used by aggregates.
+ </para>
</listitem>
</itemizedlist>
***************
*** 1218,1224 ****
<listitem>
<para>
! Allow the changing of foreign key constraint via <link
linkend="SQL-ALTERTABLE"><command>ALTER TABLE</></link>
... <literal>ALTER CONSTRAINT</> (Simon Riggs)
</para>
--- 1227,1233 ----
<listitem>
<para>
! Allow changing foreign key constraint deferrability via <link
linkend="SQL-ALTERTABLE"><command>ALTER TABLE</></link>
... <literal>ALTER CONSTRAINT</> (Simon Riggs)
</para>
***************
*** 1254,1260 ****
<listitem>
<para>
! Fully-implement the <link
linkend="datatype-line"><type>line</></link> data type (Peter
Eisentraut)
</para>
--- 1263,1269 ----
<listitem>
<para>
! Fully implement the <link
linkend="datatype-line"><type>line</></link> data type (Peter
Eisentraut)
</para>
***************
*** 1472,1478 ****
<para>
Add function <link
linkend="functions-admin-dblocation"><function>pg_filenode_relation()</></link>
! to allow for more efficient filenode to relation lookups (Andres
Freund)
</para>
</listitem>
--- 1481,1487 ----
<para>
Add function <link
linkend="functions-admin-dblocation"><function>pg_filenode_relation()</></link>
! to allow for more efficient lookup of relation names from filenodes (Andres
Freund)
</para>
</listitem>
***************
*** 1543,1552 ****
</listitem>
<listitem>
- <!-- FIXME -->
<para>
Allow polymorphic aggregates to have non-polymorphic state data
! types ? (Tom Lane)
</para>
</listitem>
--- 1552,1564 ----
</listitem>
<listitem>
<para>
Allow polymorphic aggregates to have non-polymorphic state data
! types (Tom Lane)
! </para>
! <para>
! This allows the declaration of aggregates like the built-in
! aggregate <function>array_agg()</> in SQL.
</para>
</listitem>
***************
*** 1772,1778 ****
<listitem>
<para>
! Allow field wrapping to <application>psql</>'s "extended" mode
(Sergey Muraviov)
</para>
</listitem>
--- 1784,1791 ----
<listitem>
<para>
! Add ability to wrap long lines in <application>psql</>'s
! <literal>expanded</> mode by using <command>\pset format wrapped</>
(Sergey Muraviov)
</para>
</listitem>
***************
*** 2218,2224 ****
<listitem>
<para>
Add <link linkend="pgprewarm"><application>pg_prewarm</></link>
! to preload relation data into the shared buffer cache (Robert Haas)
</para>
<para>
--- 2231,2238 ----
<listitem>
<para>
Add <link linkend="pgprewarm"><application>pg_prewarm</></link>
! extension to preload relation data into the shared buffer cache
! (Robert Haas)
</para>
<para>
***************
*** 2243,2249 ****
<listitem>
<para>
! Add logging of trigger execution to <link
linkend="auto-explain"><application>auto_explain</></link>
(Horiguchi Kyotaro)
</para>
--- 2257,2263 ----
<listitem>
<para>
! Add option to include trigger execution time to <link
linkend="auto-explain"><application>auto_explain</></link>
(Horiguchi Kyotaro)
</para>
***************
*** 2279,2287 ****
<listitem>
<para>
! Improve indexing of <link
! linkend="pgtrgm"><application>pg_trgm</></link> values to
! discourage indexing whitespace (Alexander Korotkov)
</para>
</listitem>
--- 2293,2302 ----
<listitem>
<para>
! Improve <link linkend="pgtrgm"><application>pg_trgm</>'s</link>
! generation of trigrams for indexed regular expression searches by
! discouraging the indexing of trigrams containing whitespace (Alexander
! Korotkov)
</para>
</listitem>
***************
*** 2328,2334 ****
<listitem>
<para>
! Allow pgbench to process script files of any line length (Sawada
Masahiko)
</para>
--- 2343,2349 ----
<listitem>
<para>
! Allow <application>pgbench</> to process script files of any line length (Sawada
Masahiko)
</para>
***************
*** 2339,2358 ****
<listitem>
<para>
! Add <application>pg_bench</> option (<option>--rate</>) to control
the transaction rate (Fabien Coelho)
</para>
</listitem>
<listitem>
<para>
! Add <option>--progress</> output option to pgbench (Fabien Coelho)
</para>
</listitem>
<listitem>
<para>
! Add long options to pgbench (Fabien Coelho)
</para>
</listitem>
--- 2354,2373 ----
<listitem>
<para>
! Add <application>pgbench</> option (<option>--rate</>) to control
the transaction rate (Fabien Coelho)
</para>
</listitem>
<listitem>
<para>
! Add <option>--progress</> output option to <application>pgbench</> (Fabien Coelho)
</para>
</listitem>
<listitem>
<para>
! Add long options to <application>pgbench</> (Fabien Coelho)
</para>
</listitem>
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
Attachments:
rel.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
new file mode 100644
index 91a586f..41256b7
*** a/doc/src/sgml/release-9.4.sgml
--- b/doc/src/sgml/release-9.4.sgml
***************
*** 89,95 ****
linkend="functions-formatting-table"><function>to_timestamp()</></link>
and <function>to_date()</> format strings to consume a corresponding
number of characters in the input string (whitespace or not), then
! conditionally additional adjacent whitespace if not in <literal>FX</>
mode (Jeevan Chalke)
</para>
--- 89,95 ----
linkend="functions-formatting-table"><function>to_timestamp()</></link>
and <function>to_date()</> format strings to consume a corresponding
number of characters in the input string (whitespace or not), then
! conditionally consume adjacent whitespace if not in <literal>FX</>
mode (Jeevan Chalke)
</para>
***************
*** 98,104 ****
format string behaved like a single whitespace character and consumed
all adjacent whitespace in the input string. For example, previously
format string space-space-space would consume only the first space in
! ' 12', while it will not consume all three characters.
</para>
</listitem>
--- 98,104 ----
format string behaved like a single whitespace character and consumed
all adjacent whitespace in the input string. For example, previously
format string space-space-space would consume only the first space in
! ' 12', while it will now consume all three characters.
</para>
</listitem>
***************
*** 122,128 ****
</para>
<para>
! Previously empty arrays were returned as one-dimensional empty arrays
whose text representation looked the same as zero-dimensional arrays
(<literal>{}</>). <application>intarray</>'s behavior in this area
now matches the built-in array operators.
--- 122,128 ----
</para>
<para>
! Previously, empty arrays were returned as one-dimensional empty arrays
whose text representation looked the same as zero-dimensional arrays
(<literal>{}</>). <application>intarray</>'s behavior in this area
now matches the built-in array operators.
***************
*** 131,139 ****
<listitem>
<para>
! NULL <link
linkend="xfunc-sql-variadic-functions"><literal>VARIADIC</></link>
! function arguments are now disallowed (Pavel Stehule)
</para>
<para>
--- 131,139 ----
<listitem>
<para>
! Disallow NULL <link
linkend="xfunc-sql-variadic-functions"><literal>VARIADIC</></link>
! function arguments (Pavel Stehule)
</para>
<para>
***************
*** 300,306 ****
<listitem>
<para>
! <command>DISCARD ALL</> now also discards the state of sequences.
</para>
</listitem>
--- 300,306 ----
<listitem>
<para>
! <command>DISCARD ALL</> now also discards sequence state.
</para>
</listitem>
***************
*** 366,372 ****
<listitem>
<para>
! During immediate shutdown, send uncatchable termination signals
to child processes that have not already shutdown (MauMau,
Álvaro Herrera)
</para>
--- 366,372 ----
<listitem>
<para>
! During immediate shutdown send uncatchable termination signals
to child processes that have not already shutdown (MauMau,
Álvaro Herrera)
</para>
***************
*** 740,746 ****
<para>
In contrast
! to <link linkend="guc-local-preload-libraries"><varname>local_preload_libraries</></link>,
this parameter can load any shared library, not just those in
the <filename>$libdir/plugins</> directory.
</para>
--- 740,746 ----
<para>
In contrast
! to <link linkend="guc-local-preload-libraries"><varname>local_preload_libraries</></link>
this parameter can load any shared library, not just those in
the <filename>$libdir/plugins</> directory.
</para>
***************
*** 789,796 ****
<listitem>
<para>
Have Windows <acronym>ASCII</>-encoded databases and server process
! (e.g. <link linkend="app-postmaster">postmaster) emit messages
! in the <envar>LC_CTYPE</></link>-defined language (Alexander Law,
Noah Misch)
</para>
--- 789,796 ----
<listitem>
<para>
Have Windows <acronym>ASCII</>-encoded databases and server process
! (e.g. <link linkend="app-postmaster">postmaster</>) emit messages
! in the <envar>LC_CTYPE</>-defined language (Alexander Law,
Noah Misch)
</para>
***************
*** 994,1000 ****
<listitem>
<para>
Add <link linkend="queries-tablefunctions"><literal>WITH
! ORDINALITY</></link> syntax which numbers rows returned from
<literal>FROM</>-clause functions (Andrew Gierth, David Fetter)
</para>
--- 994,1000 ----
<listitem>
<para>
Add <link linkend="queries-tablefunctions"><literal>WITH
! ORDINALITY</></link> syntax to number rows returned from
<literal>FROM</>-clause functions (Andrew Gierth, David Fetter)
</para>
***************
*** 1042,1048 ****
Add <command>FORCE NULL</> option
to <link linkend="SQL-COPY"><command>COPY FROM</></link> which causes
quoted strings matching the null string to be converted to NULL in
! in <literal>CSV</> mode (Ian Barwick, Michael Paquier)
</para>
<para>
--- 1042,1048 ----
Add <command>FORCE NULL</> option
to <link linkend="SQL-COPY"><command>COPY FROM</></link> which causes
quoted strings matching the null string to be converted to NULL in
! <literal>CSV</> mode (Ian Barwick, Michael Paquier)
</para>
<para>
***************
*** 1178,1184 ****
<listitem>
<para>
! Improve the internal definition of system relations (Andres Freund,
Robert Haas)
</para>
--- 1178,1184 ----
<listitem>
<para>
! Improve how system-level relations are designated (Andres Freund,
Robert Haas)
</para>
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
Attachments:
rel.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
new file mode 100644
index 41256b7..2913944
*** a/doc/src/sgml/release-9.4.sgml
--- b/doc/src/sgml/release-9.4.sgml
***************
*** 1327,1334 ****
<para>
This allows for faster access to values in the <type>JSON</>
document and faster and more useful indexing of <type>JSON</>.
! <type>JSONB</> values are also typed as appropriate scalar
! SQL types.
</para>
</listitem>
--- 1327,1334 ----
<para>
This allows for faster access to values in the <type>JSON</>
document and faster and more useful indexing of <type>JSON</>.
! Scalar values in <type>JSONB</> documents are typed as appropriate
! scalar SQL types.
</para>
</listitem>
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 19, 2014 at 10:23 AM, Bruce Momjian <bruce@momjian.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@momjian.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@momjian.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-multipleexpansion?
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@momjian.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@momjian.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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, May 4, 2014 at 5:46 AM, Bruce Momjian <bruce@momjian.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
Attachments:
relnotes94-nm-v1.patchtext/plain; charset=us-asciiDownload
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
index 3f30c63..d9f9828 100644
--- a/doc/src/sgml/release-9.4.sgml
+++ b/doc/src/sgml/release-9.4.sgml
@@ -573,8 +573,9 @@
<listitem>
<para>
- Allow sorting and B-tree <link linkend="SQL-CREATEINDEX">index
- builds</link> to use over four gigabytes of memory (Noah Misch)
+ Raise hard limit on the number of tuples held in memory during sorting
+ and B-tree <link linkend="SQL-CREATEINDEX">index builds</link> (Noah
+ Misch)
</para>
</listitem>
@@ -615,7 +616,7 @@
<listitem>
<para>
Expose the estimation of number of changed tuples since last <link
- linkend="vacuum-for-statistics">analyze</link> (Mark Kirkwood)
+ linkend="vacuum-for-statistics">ANALYZE</link> (Mark Kirkwood)
</para>
<para>
@@ -838,14 +839,14 @@
<listitem>
<para>
- Have Windows <acronym>ASCII</>-encoded databases and server process
- (e.g. <link linkend="app-postmaster">postmaster</>) emit messages
- in the <envar>LC_CTYPE</>-defined language (Alexander Law,
- Noah Misch)
+ Have Windows <literal>SQL_ASCII</>-encoded databases and server
+ process (e.g. <link linkend="app-postmaster">postmaster</>) emit
+ messages in the character encoding of the server's Windows user locale
+ (Alexander Law, Noah Misch)
</para>
<para>
- Previously these messages were output using the Windows
+ Previously these messages were output in the Windows
<acronym>ANSI</> code page.
</para>
</listitem>
@@ -985,7 +986,7 @@
<para>
Allow <link
linkend="app-pgrecvlogical"><application>pg_recvlogical</></link>
- to receive data logical decoding data (Andres Freund)
+ to receive logical decoding data (Andres Freund)
</para>
</listitem>
@@ -1445,9 +1446,8 @@
<listitem>
<para>
- Add <acronym>SQL</> functions to allow <link
- linkend="lo-interfaces">large object reads/writes</link> at
- arbitrary offsets (Pavel Stehule)
+ Add <acronym>SQL</> functions to allow <link linkend="lo-funcs">large
+ object reads/writes</link> at arbitrary offsets (Pavel Stehule)
</para>
</listitem>
@@ -2078,7 +2078,7 @@
<listitem>
<para>
- Remove <function>SnapshotNow()</> and
+ Remove <varname>SnapshotNow</> and
<function>HeapTupleSatisfiesNow()</> (Robert Haas)
</para>
@@ -2090,8 +2090,8 @@
<listitem>
<para>
- Add <acronym>API</> for memory allocations over four gigabytes
- (Noah Misch)
+ Add <acronym>API</> for memory allocations over one gigabyte (Noah
+ Misch)
</para>
</listitem>
@@ -2229,7 +2229,7 @@
<listitem>
<para>
- Improve <application>valgrind</> error reporting (Noah Misch)
+ Improve <application>Valgrind</> error reporting (Noah Misch)
</para>
</listitem>
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@momjian.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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
Attachments:
valgrind.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
new file mode 100644
index d9f9828..5868529
*** a/doc/src/sgml/release-9.4.sgml
--- b/doc/src/sgml/release-9.4.sgml
***************
*** 2229,2235 ****
<listitem>
<para>
! Improve <application>Valgrind</> error reporting (Noah Misch)
</para>
</listitem>
--- 2229,2236 ----
<listitem>
<para>
! Improve <application>Valgrind</> detection of invalid memory usage
! (Noah Misch)
</para>
</listitem>