Skip to content

Wöchentlicher PostgreSQL Newsletter - 07. November 2010



Der Originalartikel befindet sich unter:

http://www.postgresql.org/community/weeklynews/pwn20101107



== Wöchentlicher PostgreSQL Newsletter - 07. November 2010 ==

PostgreSQL 9.1Alpha2 erschienen. Hier zum herunterladen:
http://developer.postgresql.org/pgdocs/postgres/release-9-1-alpha.html
Hier ist die Anleitung zum Testen:
http://wiki.postgresql.org/wiki/HowToBetaTest

BuildFarm Client 4.4 ist erschienen. Bitte nimm an der Buildfarm
teil, speziell wenn du eine ungewöhnliche Hardware/OS/Compiler
Kombination hast.

FOSDEM ist eine der größten Freien und Open Source Veranstaltungen
und findet jährlich in Brüssel, Belgien statt, nächstes Jahr am
5. und 6. Februar 2011. Ungefähr 4.000 Besucher finden sich dort ein.
Sende deine Vorträge an fosdem AT postgresql DOT eu.
http://andreas.scherbaum.la/blog/archives/749-PostgreSQLFOSDEM-2011-Call-for-talks.html

NYPUG präsentiert Mladen Gogala, er wird über das Portieren Oracle
nach PostgreSQL sprechen. Am 9. November, Details unter:
http://www.meetup.com/postgresql-3/calendar/15273949/

Frühbucherregistrierung für PGDay.IT am 10. Dezember 2010 in Rom,
Italien ist jetzt offen und der Vortragsplan ist online.
http://2010.pgday.it/

== PostgreSQL Produkt Neuigkeiten ==

Npgsql 2.0.11, ein .NET Treiber für PostgreSQL, ist erschienen.
http://www.npgsql.org

== PostgreSQL Jobs im November ==

http://archives.postgresql.org/pgsql-jobs/2010-11/threads.php

== PostgreSQL Lokal ==

PostgreSQL Stand und BOF auf der Usenix LISA, am
10. und 11. November in San Jose CA.
http://www.usenix.org/event/lisa10/

Die Deutsche PostgreSQL Anwendergruppe hat einen Stand auf der
OpenRheinRuhr 2010 am 13. und 14. November in Oberhausen,
Deutschland. Andreas Scherbaum hält einen Vortrag über neue
Features in PostgreSQL 9.0.
http://andreas.scherbaum.la/blog/archives/744-PostgreSQL-OpenRheinRuhr-2010.html

Die Deutsche PostgreSQL Anwendergruppe ist mit einem Stand, einem
Vortrag und einem Workshop auf dem Brandenburger Linux-Infotag 2010
in Potsdam, Deutschland am 6. November 2010 präsent.
http://andreas.scherbaum.la/blog/archives/746-PostgreSQL-Brandenburger-Linux-Infotag-2010.html

Registrierung für PGDay.EU 2010 vom 6. bis 8. Dezember in
Stuttgart, Deutschland ist jetzt offen.
http://2010.pgday.eu/register

PgDay.IT 2010 wird am 10. Dezember in Rom stattfinden. Der Call for
Papers ist jetzt offen.
http://www.pgday.it/

PGDay findet dieses Jahr während der südkalifornischen Linux Ausstellung
(SCALE) im LAX Hilton Hotel in Los Angeles, Kalifornien am Freitag dem
25. Februar 2011 statt. Vorträge kannst du unter pgday-submissions AT
googlegroups DOT com einreichen.

== PostgreSQL in den News ==

Planet PostgreSQL: http://planet.postgresql.org/

Dieser wöchentliche PostgreSQL Newsletter wurde erstellt von David Fetter.

Sende Neuigkeiten und Ankündigungen bis Sonntag, 15 Uhr Pazifischer
Zeit. Bitte sende englische Beiträge an david@fetter.org, deutsche an
pwn@pgug.de, italienische an pwn@itpug.org.



== Reviews ==

== Angewandte Patches ==

Heikki Linnakangas pushed:

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=931b6db39b808608a3c80c42b47e3cbcda9e66db

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=8c843fff2d8db7889b81782ab4f3324cbda4ed2a

Tom Lane pushed:

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=0811ff2063be973953eda89e76dac0d299f0fb6b

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=9f376e146b2f1fe1bc4d07380f2a047d5c375581

- Fix buffer overrun in pg_upgrade.  Problem reported, and cause
  identified, by Hernan Gonzalez.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=71baff1786e0c50b514745c64c4b0947b64bf9d0

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=61d6dd0c03eb4da654f435097cd0bf1da11c3272

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=70a0160b07b66dc7fa1555c489330ea8fb58f8fe

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=0abc8fdd4df3dd0524cd9fd8e2d761cf932dd80f

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=034967bdcbb0c7be61d0500955226e1234ec5f04

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=09211659d9d8fd62f9de09703c90ed4f072c4a47

- Allow moddatetime's target column to be of type timestamptz.  Dirk
  Heinrichs.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=5e8b7b0b73b6d0aba4a5a05704601dd031ad0a49

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=6736916f5f5a5f340aa20d4b27540764b5646585

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=dd1c781903811416db4e03383a4cb0bfc8cfac40

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=d7a2ce4905da7d812407b6354f038aac17e97024

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=e43fb604d6db229d70d3101aa53348cc16a5473a

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=543d22fc7423747afd59fe7214f2ddf6259efc62

Michael Meskes pushed:

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=35d5d962e1777560baf6f5edec906a907a853c9a

Peter Eisentraut pushed:

- 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.
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=dd21f0b047078ae724c0de4bc87b175154a83707

== Abgelehnte Patches (bis jetzt) ==

No one was disappointed this week :-)

== Eingesandte Patches ==

Andres Freund sent in two more patches to make COPY more efficient by
creating and using custom integer-to-string conversion routines.

Alex Hunsaker sent in two patches to fix the way PL/Tcl handles
trigger functions analogous to the fix for PL/Perl.

Hitoshi Harada sent in a patch to change sort states to plan states in
some parts of the explain and the executor.

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.

Dimitri Fontaine sent a patch to add execute_from_file().

Peter Eisentraut sent in a patch intended to improve support for
parallel make.

Dimitri Fontaine sent in a patch to add pg_dump support for
EXTENSIONs.

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.

ITAGAKI Takahiro sent in a patch to change boolean==true to boolean in
the source code.

Alexander Korotkov and Yeb Havinga traded patches to fix the picksplit
function in the seg contrib module.

KaiGai Kohei sent in a contrib module to allow delaying auth.

Fujii Masao sent in a patch to allow tracking the most recently
replayed transaction.

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.

Alvaro Herrera sent in a patch to better document the now-less-dusty
CREATE CONSTRAINT TRIGGER syntax.

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.

Tom Lane sent in a patch to fix an issue with how UNION ALL was
handled.

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.

  • Twitter
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 07. November 2010 at del.icio.us
  • Facebook
  • Google Bookmarks
  • FriendFeed
  • Digg Wöchentlicher PostgreSQL Newsletter - 07. November 2010
  • Bloglines Wöchentlicher PostgreSQL Newsletter - 07. November 2010
  • Technorati Wöchentlicher PostgreSQL Newsletter - 07. November 2010
  • Fark this: Wöchentlicher PostgreSQL Newsletter - 07. November 2010
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 07. November 2010 at YahooMyWeb
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 07. November 2010 at Furl.net
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 07. November 2010 at reddit.com
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 07. November 2010 at blinklist.com
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 07. November 2010 at Spurl.net
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 07. November 2010 at Simpy.com
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 07. November 2010 at blogmarks
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 07. November 2010 with wists
  • wong it!
  • Bookmark using any bookmark manager!
  • Stumble It!
  • Identi.ca

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

No comments

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
To leave a comment you must approve it via e-mail, which will be sent to your address after submission.
Form options