--- /dev/null
+<!-- BEGIN page_title_block -->
+Weekly News - November 07 2010
+<!-- END page_title_block -->
+
+<h1>PostgreSQL Weekly News - November 07 2010</h1>
+
+<p>
+PostgreSQL 9.1alpha2 released. Get it here:
+<a href="http://developer.postgresql.org/pgdocs/postgres/release-9-1-alpha.html">http://developer.postgresql.org/pgdocs/postgres/release-9-1-alpha.html</a>
+Here's how to test it:
+<a href="http://wiki.postgresql.org/wiki/HowToBetaTest">http://wiki.postgresql.org/wiki/HowToBetaTest</a>
+</p>
+
+<p>
+BuildFarm client 4.4 released. Please join the buildfarm, especially
+if you have an unusual hardware/OS/compiler combination.
+<a href="http://pgfoundry.org/projects/pgbuildfarm/">http://pgfoundry.org/projects/pgbuildfarm/</a>
+</p>
+
+<p>
+FOSDEM is one of the biggest Free and Open Source event held annually
+in Brussels, Belgium, on February 5-6, 2011, and attended by around
+4000 people. Send in your proposal to fosdem AT postgresql DOT eu.
+<a href="http://andreas.scherbaum.la/blog/archives/749-PostgreSQLFOSDEM-2011-Call-for-talks.html">http://andreas.scherbaum.la/blog/archives/749-PostgreSQLFOSDEM-2011-Call-for-talks.html</a>
+</p>
+
+<p>
+NYPUG presents Mladen Gogala, who will speak on moving from Oracle to
+PostgreSQL Tuesday, November 9. Details below.
+<a href="http://www.meetup.com/postgresql-3/calendar/15273949/">http://www.meetup.com/postgresql-3/calendar/15273949/</a>
+</p>
+
+<p>
+Early bird registration for PGDay.IT, December 10, 2010 in Rome,
+Italy, is open and the schedule is online.
+<a href="http://2010.pgday.it/">http://2010.pgday.it/</a>
+</p>
+
+<h2>PostgreSQL Product News</h2>
+<p>
+Npgsql 2.0.11, a .NET data provider for PostgreSQL, released.
+<a href="http://www.npgsql.org">http://www.npgsql.org</a>
+</p>
+
+<h2>PostgreSQL Jobs for November</h2>
+<p>
+<a href="http://archives.postgresql.org/pgsql-jobs/2010-11/threads.php">http://archives.postgresql.org/pgsql-jobs/2010-11/threads.php</a>
+</p>
+
+<h2>PostgreSQL Local</h2>
+<p>
+PostgreSQL Booth and BOF at Usenix LISA, November 10-11, San Jose CA
+<a href="http://www.usenix.org/event/lisa10/">http://www.usenix.org/event/lisa10/</a>
+</p>
+
+<p>
+The German PostgreSQL User Group is running a booth at OpenRheinRuhr
+2010 on november 13rd and 14th in Oberhausen, Germany. Andreas
+Scherbaum is giving a talk about new features in PostgreSQL 9.0.
+<a href="http://andreas.scherbaum.la/blog/archives/744-PostgreSQL-OpenRheinRuhr-2010.html">http://andreas.scherbaum.la/blog/archives/744-PostgreSQL-OpenRheinRuhr-2010.html</a>
+</p>
+
+<p>
+The German PostgreSQL User Group is present with a booth, a talk and a
+workshop at Brandenburger Linux-Infotag 2010 in Potsdam, Germany on
+November 6th.
+<a href="http://andreas.scherbaum.la/blog/archives/746-PostgreSQL-Brandenburger-Linux-Infotag-2010.html">http://andreas.scherbaum.la/blog/archives/746-PostgreSQL-Brandenburger-Linux-Infotag-2010.html</a>
+</p>
+
+<p>
+Registration for PGDay.EU 2010 held on December 6-8 in Stuttgart,
+Germany is open.
+<a href="http://2010.pgday.eu/register">http://2010.pgday.eu/register</a>
+</p>
+
+<p>
+PgDay.IT 2010 will be in Rome this year December 10th. The Call for
+Papers is now open.
+<a href="http://www.pgday.it/">http://www.pgday.it/</a>
+</p>
+
+<p>
+PGDay is scheduled at this year's Southern California Linux Exposition
+(SCALE) held in the LAX Hilton Hotel in the city of Los Angeles,
+California, on Friday February 25th, 2011. Post your talk submission
+to pgday-submissions AT googlegroups DOT com.
+</p>
+
+<h2>PostgreSQL in the News</h2>
+<p>
+Planet PostgreSQL: <a href="http://planet.postgresql.org/">http://planet.postgresql.org/</a>
+</p>
+
+<p>
+PostgreSQL Weekly News is brought to you this week by David Fetter
+</p>
+
+<p>
+Submit news and announcements by Sunday at 3:00pm Pacific time.
+Please send English language ones to david@fetter.org, German language
+to pwn@pgug.de, Italian language to pwn@itpug.org. Spanish language
+to pwn@arpug.com.ar.
+</p>
+
+<h2>Reviews</h2>
+<h2>Applied Patches</h2>
+<p>
+Heikki Linnakangas pushed:
+</p>
+
+<p>
+- Fix corner-case bug in tracking of latest removed WAL segment during
+ streaming replication. We used log/seg 0/0 to indicate that no WAL
+ segments have been removed since startup, but 0/0 is a valid value
+ for the very first WAL segment after initdb. To make that
+ unambiguous, store (latest removed WAL segment + 1) in the global
+ variable. Per report from Matt Chesler, also reproduced by Greg
+ Smith.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=931b6db39b808608a3c80c42b47e3cbcda9e66db">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=931b6db39b808608a3c80c42b47e3cbcda9e66db</a>
+</p>
+
+<p>
+- Bootstrap WAL to begin at segment logid=0 logseg=1
+ (000000010000000000000001) rather than 0/0, so that we can safely
+ use 0/0 as an invalid value. This is a more future-proof fix for
+ the corner-case bug in streaming replication that was fixed
+ yesterday. We had a similar corner-case bug with log/seg 0/0 back
+ in February as well. Avoiding 0/0 as a valid value should prevent
+ bugs like that in the future. Per Tom Lane's idea. Back-patch to
+ 9.0. Since this only affects bootstrapping, it makes no difference
+ to existing installations. We don't need to worry about the bug in
+ existing installations, because if you've managed to get past the
+ initial base backup already, you won't hit the bug in the future
+ either.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=8c843fff2d8db7889b81782ab4f3324cbda4ed2a">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=8c843fff2d8db7889b81782ab4f3324cbda4ed2a</a>
+</p>
+
+<p>
+Tom Lane pushed:
+</p>
+
+<p>
+- Avoid using a local FunctionCallInfoData struct in
+ ExecMakeFunctionResult and related routines. We already had a
+ redundant FunctionCallInfoData struct in FuncExprState, but were
+ using that copy only in set-returning-function cases, to avoid
+ keeping function evaluation state in the expression tree for the
+ benefit of plpgsql's "simple expression" logic. But of course that
+ didn't work anyway. Given the recent fixes in plpgsql there is no
+ need to have two separate behaviors here. Getting rid of the local
+ FunctionCallInfoData structs should make things a little faster
+ (because we don't need to do InitFunctionCallInfoData each time),
+ and it also makes for a noticeable reduction in stack space
+ consumption during recursive calls.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=0811ff2063be973953eda89e76dac0d299f0fb6b">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=0811ff2063be973953eda89e76dac0d299f0fb6b</a>
+</p>
+
+<p>
+- Ensure an index that uses a whole-row Var still depends on its
+ table. We failed to record any dependency on the underlying table
+ for an index declared like "create index i on t (foo(t.*))". This
+ would create trouble if the table were dropped without previously
+ dropping the index. To fix, simplify some overly-cute code in
+ index_create(), accepting the possibility that sometimes the
+ whole-table dependency will be redundant. Also document this hazard
+ in dependency.c. Per report from Kevin Grittner. In passing,
+ prevent a core dump in pg_get_indexdef() if the index's table can't
+ be found. I came across this while experimenting with Kevin's
+ example. Not sure it's a real issue when the catalogs aren't
+ corrupt, but might as well be cautious. Back-patch to all supported
+ versions.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=9f376e146b2f1fe1bc4d07380f2a047d5c375581">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=9f376e146b2f1fe1bc4d07380f2a047d5c375581</a>
+</p>
+
+<p>
+- Fix buffer overrun in pg_upgrade. Problem reported, and cause
+ identified, by Hernan Gonzalez.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=71baff1786e0c50b514745c64c4b0947b64bf9d0">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=71baff1786e0c50b514745c64c4b0947b64bf9d0</a>
+</p>
+
+<p>
+- Fix adjust_semi_join to be more cautious about clauseless joins. It
+ was reporting that these were fully indexed (hence cheap), when of
+ course they're the exact opposite of that. I'm not certain if the
+ case would arise in practice, since a clauseless semijoin is hard to
+ produce in SQL, but if it did happen we'd make some dumb decisions.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=61d6dd0c03eb4da654f435097cd0bf1da11c3272">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=61d6dd0c03eb4da654f435097cd0bf1da11c3272</a>
+</p>
+
+<p>
+- Use only one hash entry for all instances of a pltcl trigger
+ function. Like plperl and unlike plpgsql, there isn't any cached
+ state that could depend on exactly which relation the trigger is
+ being fired for. So we can use just one hash entry for all
+ relations, which might save a little something. Alex Hunsaker.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=70a0160b07b66dc7fa1555c489330ea8fb58f8fe">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=70a0160b07b66dc7fa1555c489330ea8fb58f8fe</a>
+</p>
+
+<p>
+- Reduce recursion depth in recently-added regression test. Some
+ buildfarm members fail the test with the original depth of 10
+ levels, apparently because they are running at the minimum
+ max_stack_depth setting of 100kB and using ~ 10k per recursion
+ level. While it might be interesting to try to figure out why
+ they're eating so much stack, it isn't likely that any fix for that
+ would be back-patchable. So just change the test to recurse only 5
+ levels. The extra levels don't prove anything correctness-wise
+ anyway.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=0abc8fdd4df3dd0524cd9fd8e2d761cf932dd80f">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=0abc8fdd4df3dd0524cd9fd8e2d761cf932dd80f</a>
+</p>
+
+<p>
+- Reimplement planner's handling of MIN/MAX aggregate optimization.
+ Per my recent proposal, get rid of all the direct inspection of
+ indexes and manual generation of paths in planagg.c. Instead, set
+ up EquivalenceClasses for the aggregate argument expressions, and
+ let the regular path generation logic deal with creating paths that
+ can satisfy those sort orders. This makes planagg.c a bit more
+ visible to the rest of the planner than it was originally, but the
+ approach is basically a lot cleaner than before. A major advantage
+ of doing it this way is that we get MIN/MAX optimization on
+ inheritance trees (using MergeAppend of indexscans) practically for
+ free, whereas in the old way we'd have had to add a whole lot more
+ duplicative logic. One small disadvantage of this approach is that
+ MIN/MAX aggregates can no longer exploit partial indexes having an
+ "x IS NOT NULL" predicate, unless that restriction or something that
+ implies it is specified in the query. The previous implementation
+ was able to use the added "x IS NOT NULL" condition as an extra
+ predicate proof condition, but in this version we rely entirely on
+ indexes that are considered usable by the main planning process.
+ That seems a fair tradeoff for the simplicity and functionality
+ gained.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=034967bdcbb0c7be61d0500955226e1234ec5f04">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=034967bdcbb0c7be61d0500955226e1234ec5f04</a>
+</p>
+
+<p>
+- Use appendStringInfoString() where appropriate in elog.c. The
+ nominally equivalent call appendStringInfo(buf, "%s", str) can be
+ significantly slower when str is large. In particular, the former
+ usage in EVALUATE_MESSAGE led to O(N^2) behavior when collecting a
+ large number of context lines, as I found out while testing
+ recursive functions. The other changes are just neatnik-ism and
+ seem unlikely to save anything meaningful, but a cycle shaved is a
+ cycle earned.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=09211659d9d8fd62f9de09703c90ed4f072c4a47">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=09211659d9d8fd62f9de09703c90ed4f072c4a47</a>
+</p>
+
+<p>
+- Allow moddatetime's target column to be of type timestamptz. Dirk
+ Heinrichs.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=5e8b7b0b73b6d0aba4a5a05704601dd031ad0a49">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=5e8b7b0b73b6d0aba4a5a05704601dd031ad0a49</a>
+</p>
+
+<p>
+- Include the current value of max_stack_depth in stack depth
+ complaints. I'm mainly interested in finding out what it is on
+ buildfarm machines, but including the active value in the message
+ seems like good practice in any case. Add the info to the HINT, not
+ the ERROR string, so as not to change the regression tests' expected
+ output.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=6736916f5f5a5f340aa20d4b27540764b5646585">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=6736916f5f5a5f340aa20d4b27540764b5646585</a>
+</p>
+
+<p>
+- Make get_stack_depth_rlimit() handle RLIM_INFINITY more sanely.
+ Rather than considering this result as meaning "unknown", report
+ LONG_MAX. This won't change what superusers can set max_stack_depth
+ to, but it will cause InitializeGUCOptions() to set the built-in
+ default to 2MB not 100kB. The latter seems like a fairly
+ unreasonable interpretation of "infinity". Per my investigation of
+ odd buildfarm results as well as an old complaint from Heikki.
+ Since this should persuade all the buildfarm animals to use a
+ reasonable stack depth setting during "make check", revert previous
+ patch that dumbed down a recursive regression test to only 5 levels.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=dd1c781903811416db4e03383a4cb0bfc8cfac40">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=dd1c781903811416db4e03383a4cb0bfc8cfac40</a>
+</p>
+
+<p>
+- Add support for detecting register-stack overrun on IA64. Per
+ recent investigation, the register stack can grow faster than the
+ regular stack depending on compiler and choice of options. To avoid
+ crashes we must check both stacks in check_stack_depth().
+ Back-patch to all supported versions.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=d7a2ce4905da7d812407b6354f038aac17e97024">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=d7a2ce4905da7d812407b6354f038aac17e97024</a>
+</p>
+
+<p>
+- Implement an "S" option for psql's \dn command. \dn without "S" now
+ hides all pg_XXX schemas as well as information_schema. Thus, in a
+ bare database you'll only see "public". ("public" is considered a
+ user schema, not a system schema, mainly because it's droppable.)
+ Per discussion back in late September.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=e43fb604d6db229d70d3101aa53348cc16a5473a">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=e43fb604d6db229d70d3101aa53348cc16a5473a</a>
+</p>
+
+<p>
+- Prevent invoking I/O conversion casts via functional/attribute
+ notation. PG 8.4 added a built-in feature for casting
+ pretty much any data type to string types (text, varchar, etc). We
+ allowed this to work in any of the historically-allowed syntaxes:
+ CAST(x AS text), x::text, text(x), or x.text. However, multiple
+ complaints have shown that it's too easy to invoke such casts
+ unintentionally in the latter two styles, particularly field
+ selection. To cure the problem with the narrowest possible change
+ of behavior, disallow use of I/O conversion casts from composite
+ types to string types via functional/attribute syntax. The new
+ functionality is still available via cast syntax. In passing,
+ document the equivalence of functional and attribute syntax in a
+ more visible place.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=543d22fc7423747afd59fe7214f2ddf6259efc62">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=543d22fc7423747afd59fe7214f2ddf6259efc62</a>
+</p>
+
+<p>
+Michael Meskes pushed:
+</p>
+
+<p>
+- Some cleanup in ecpg code: Use bool as type for booleans instead of
+ int. Do not implicitely cast size_t to int. Make the compiler stop
+ complaining about unused variables by adding an empty statement.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=35d5d962e1777560baf6f5edec906a907a853c9a">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=35d5d962e1777560baf6f5edec906a907a853c9a</a>
+</p>
+
+<p>
+Peter Eisentraut pushed:
+</p>
+
+<p>
+- Print a make warning when using GNU make older than 3.80. A
+ proposed patch will require GNU make 3.80 or newer. We will let
+ this patch run for a while to see how much damage that would do to
+ the buildfarm.
+ <a href="http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=dd21f0b047078ae724c0de4bc87b175154a83707">http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=dd21f0b047078ae724c0de4bc87b175154a83707</a>
+</p>
+
+<h2>Rejected Patches (for now)</h2>
+<p>
+No one was disappointed this week :-)
+</p>
+
+<h2>Pending Patches</h2>
+<p>
+Andres Freund sent in two more patches to make COPY more efficient by
+creating and using custom integer-to-string conversion routines.
+</p>
+
+<p>
+Alex Hunsaker sent in two patches to fix the way PL/Tcl handles
+trigger functions analogous to the fix for PL/Perl.
+</p>
+
+<p>
+Hitoshi Harada sent in a patch to change sort states to plan states in
+some parts of the explain and the executor.
+</p>
+
+<p>
+Dimitri Fontaine and Alvaro Herrera traded several revisions of the
+patch to add ALTER OBJECT ... SET SCHEMA for the objects where this is
+not already doable.
+</p>
+
+<p>
+Dimitri Fontaine sent a patch to add execute_from_file().
+</p>
+
+<p>
+Peter Eisentraut sent in a patch intended to improve support for
+parallel make.
+</p>
+
+<p>
+Dimitri Fontaine sent in a patch to add pg_dump support for
+EXTENSIONs.
+</p>
+
+<p>
+Alex Hunsaker sent in a patch to fix the way PL/Python handles trigger
+functions similar to how he fixed PL/Perl and PL/Tcl.
+</p>
+
+<p>
+ITAGAKI Takahiro sent in a patch to change boolean==true to boolean in
+the source code.
+</p>
+
+<p>
+Alexander Korotkov and Yeb Havinga traded patches to fix the picksplit
+function in the seg contrib module.
+</p>
+
+<p>
+KaiGai Kohei sent in a contrib module to allow delaying auth.
+</p>
+
+<p>
+Fujii Masao sent in a patch to allow tracking the most recently
+replayed transaction.
+</p>
+
+<p>
+Marti Raudsepp sent in a patch to revert wal_sync_method to fdatasync
+on Linux 2.6.33 or higher because the setting changed as of that
+kernel.
+</p>
+
+<p>
+Alvaro Herrera sent in a patch to better document the now-less-dusty
+CREATE CONSTRAINT TRIGGER syntax.
+</p>
+
+<p>
+Hitoshi Harada sent in a patch to allow sharing the result data of a
+separate plan in a single execution. This is infrastructure for
+writeable CTEs.
+</p>
+
+<p>
+Tom Lane sent in a patch to fix an issue with how UNION ALL was
+handled.
+</p>
+
+<p>
+Gurjeet Singh sent in a patch to allow ALTER TABLE to point to a
+UNIQUE index which would then become a constraint, for example, a
+PRIMARY KEY constraint.
+
+</p>
+
projects / pgweb-old.git / commitdiff