== PostgreSQL Weekly News - December 23 2012 ==

== PostgreSQL Weekly News - December 23 2012 ==

FOSDEM PGDay is a one day conference that will be held before FOSDEM
in Brussels, Belgium, on Feb 1st, 2013. Details below.
http://fosdem2013.pgconf.eu/

The New York City PostgreSQL User Group is pleased to announce that
registrations for PGDay NYC 2013 on Friday, March 22, 2013 at the ACE
Hotel are now open. Super Early Bird tickets are available until they
sell out or December 29, 2012, whichever comes first. You can
purchase them at
http://pgday.nycpug.org/registration/

PyPgDay will be held on March 13th at the Santa Clara Convention
Center, the first day of PyCon. Info here:
http://wiki.postgresql.org/wiki/PyPgDay2013
Submit your proposal here by January 20, 2013:
http://tinyurl.com/PyPgDayCfP

== PostgreSQL Product News ==

Ora2PG 10 released.
http://ora2pg.darold.net/

pg_activity 0.2.0 released.
https://github.com/julmon/pg_activity/

Skytools 3.1.3, a package of tools developed by Skype for replication
and failover including PgQ, a generic queuing framework and Londiste,
a row-based master-slave replication replication system, released:
https://github.com/markokr/skytools

== PostgreSQL Jobs for December ==

http://archives.postgresql.org/pgsql-jobs/2012-12/threads.php

== PostgreSQL Local ==

The FOSDEM PGDay conference that will be held before FOSDEM in
Brussels, Belgium, on Feb 1st, 2013. The CfP for both this event and
for the PG track of FOSDEM are open.
http://fosdem2013.pgconf.eu/callforpapers/

There will be a PgDay at PyCon on March 13th, in the Santa Clara
convention center. More details once we have things organized.
Please put it on your calendar.

PGDay NYC 2013 will be held on March 22, 2013 in New York City. The
CfP submission deadline is January 7th, 2013 at noon eastern time.
papers AT nycpug DOT org.
http://pgday.nycpug.org/speakers

PostgreSQL Session will be held on March 28th, 2013 in Paris,
France. The Call for Papers is open.
http://www.postgresql-sessions.org/en/5/

PGCon 2013 will be held May 23-24 2013, in Ottawa at the University of
Ottawa. The Call for Papers is open.
http://www.pgcon.org/2013/

== PostgreSQL in the News ==

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

PostgreSQL Weekly News is brought to you this week by David Fetter

Submit news and announcements by Sunday at 3:00pm Pacific time.
Please send English language ones to david(at)fetter(dot)org, German language
to pwn(at)pgug(dot)de, Italian language to pwn(at)itpug(dot)org(dot) Spanish language
to pwn(at)arpug(dot)com(dot)ar(dot)

== Applied Patches ==

Tom Lane pushed:

- Fix failure to ignore leftover temp tables after a server crash.
During crash recovery, we remove disk files belonging to temporary
tables, but the system catalog entries for such tables are
intentionally not cleaned up right away. Instead, the first backend
that uses a temp schema is expected to clean out any leftover
objects therein. This approach requires that we be careful to
ignore leftover temp tables (since any actual access attempt would
fail), *even if their BackendId matches our session*, if we have not
yet established use of the session's corresponding temp schema.
That worked fine in the past, but was broken by commit
debcec7dc31a992703911a9953e299c8d730c778 which incorrectly removed
the rd_islocaltemp relcache flag. Put it back, and undo various
changes that substituted tests like "rel->rd_backend == MyBackendId"
for use of a state-aware flag. Per trouble report from Heikki
Linnakangas. Back-patch to 9.1 where the erroneous change was made.
In the back branches, be careful to add rd_islocaltemp in a spot in
the struct that was alignment padding before, so as not to break
existing add-on code.
http://git.postgresql.org/pg/commitdiff/6919b7e3294702adc39effd16634b2715d04f012

- Ignore libedit/libreadline while probing for standard functions.
Some versions of libedit expose bogus definitions of setproctitle(),
optreset, and perhaps other symbols that we don't want configure to
pick up on. There was a previous report of similar problems with
strlcpy(), which we addressed in commit
59cf88da91bc88978b05275ebd94ac2d980c4047, but the problem has
evidently grown in scope since then. In hopes of not having to deal
with it again in future, rearrange configure's tests for supplied
functions so that we ignore libedit/libreadline except when probing
specifically for functions we expect them to provide. Per report
from Christoph Berg, though this is slightly more aggressive than
his proposed patch.
http://git.postgresql.org/pg/commitdiff/2666a6d0b934b19d4a691b93a64c7d3208acad43

- Fix pg_extension_config_dump() to handle update cases more sanely.
If pg_extension_config_dump() is executed again for a table already
listed in the extension's extconfig, the code was blindly making a
new array entry. This does not seem useful. Fix it to replace the
existing array entry instead, so that it's possible for extension
update scripts to alter the filter conditions for configuration
tables. In addition, teach ALTER EXTENSION DROP TABLE to check for
an extconfig entry for the target table, and remove it if present.
This is not a 100% solution because it's allowed for an extension
update script to just summarily DROP a member table, and that code
path doesn't go through ExecAlterExtensionContentsStmt. We could
probably make that case clean things up if we had to, but it would
involve sticking a very ugly wart somewhere in the guts of
dependency.c. Since on the whole it seems quite unlikely that
extension updates would want to remove pre-existing configuration
tables, making the case possible with an explicit command seems
sufficient. Per bug #7756 from Regina Obe. Back-patch to 9.1 where
extensions were introduced.
http://git.postgresql.org/pg/commitdiff/343c2a865bc6c0a03358709df854ce1eac52ca45

- Fix documentation typo. "GetForeignTableColumnOptions" should be
"GetForeignColumnOptions". Noted by Metin Döşlü.
http://git.postgresql.org/pg/commitdiff/eb035068121532ed7db47081e71655746d31cd16

- Prevent failure when RowExpr or XmlExpr is parse-analyzed twice.
transformExpr() is required to cope with already-transformed
expression trees, for various ugly-but-not-quite-worth-cleaning-up
reasons. However, some of its newer subroutines hadn't gotten the
memo. This accounts for bug #7763 from Norbert Buchmuller:
transformRowExpr() was overwriting the previously determined type of
a RowExpr during CREATE TABLE LIKE INCLUDING INDEXES. Additional
investigation showed that transformXmlExpr had the same kind of
problem, but all the other cases seem to be safe. Andres Freund and
Tom Lane
http://git.postgresql.org/pg/commitdiff/31bc839724439440b2e94ea616b28ce5be94e19c

Peter Eisentraut pushed:

- doc: Put PL/pgSQL RAISE USING keywords into a list. Karl O. Pinc
http://git.postgresql.org/pg/commitdiff/8d2e9a9dbd56aabb9273fbc30ca6c03d6f24b996

- Remove allow_nonpic_in_shlib This was used in a time when a shared
libperl or libpython was difficult to come by. That is obsolete,
and the idea behind the flag was never fully portable anyway and
will likely fail on more modern CPU architectures.
http://git.postgresql.org/pg/commitdiff/1a5f04dd7eed0ac27cc5da9520ef55e16531bca6

- pg_basebackup: Small message punctuation improvements
http://git.postgresql.org/pg/commitdiff/6925e38dadca0e64e8528316ccee7591fe88331f

- Rename SQL feature S403 to ARRAY_MAX_CARDINALITY. In an earlier
version of the standard, this was called just "MAX_CARDINALITY".
http://git.postgresql.org/pg/commitdiff/f2b88080db43fbadaef990a1b240bd634d1d4275

- Fix grammatical mistake in error message
http://git.postgresql.org/pg/commitdiff/a0bfb7b36e0795a1c69c86b4184ee952dbb650d1

- Make some messages more consistent in style
http://git.postgresql.org/pg/commitdiff/740ee42da5fc07e5b1be5c358673224d99cb2aae

Andrew Dunstan pushed:

- Don't include postgres.h in postgres_fe.h for cpluspluscheck. Error
exposed by recent Assert changes. Complaint from Peter Eisentraut.
http://git.postgresql.org/pg/commitdiff/9ac749ceb5ad040dc2aa834d9f698a3da2425a96

Heikki Linnakangas pushed:

- Check if we've reached end-of-backup point also if no redo is
required. If you restored from a backup taken from a standby, and
the last record in the backup is the checkpoint record, ie. there is
no redo required except for the checkpoint record, we would fail to
notice that we've reached the end-of-backup point, and the database
is consistent. The result was an error "WAL ends before end of
online backup". To fix, move the have-we-reached-end-of-backup check
into CheckRecoveryConsistency(), which is already responsible for
similar checks with minRecoveryPoint, and is called in the right
places. Backpatch to 9.2, this check and bug did not exist before
that.
http://git.postgresql.org/pg/commitdiff/e43f947bf32f3ea4caa5b895ca7c7659b17192ae

- Don't set ThisTimeLineID in checkpointer & bgwriter during recovery.
We used to set it to the current recovery target timeline, but the
recovery target timeline can change during recovery, leaving
ThisTimeLineID at an old value. That seems worse than always leaving
it at zero to begin with. AFAICS there was no good reason to set it
in the first place. ThisTimeLineID is not needed in checkpointer or
bgwriter process, until it's time to write the end-of-recovery
checkpoint, and at that point ThisTimeLineID is updated anyway.
http://git.postgresql.org/pg/commitdiff/1a11d4609efaae39d9b7472fb965bca1c0aeda01

- Fix recycling of WAL segments after switching timeline during
recovery. This was broken before, we would recycle old WAL segments
on wrong timeline after the recovery target timeline had changed,
but my recent commit to not initialize ThisTimeLineID at all in a
standby's checkpointer process broke this completely. The problem
is that when installing a recycled WAL segment as a future one,
ThisTimeLineID is used to construct the filename. To fix, always
update ThisTimeLineID to the current timeline being recovered,
before recycling WAL segments at a restartpoint. This still leaves
a small window where we might install WAL segments under wrong
timeline ID, if the timeline is changed just as we're about to start
recycling. Also, even if we're replaying timeline X at the momnent,
there's no guarantee that we'll need as many WAL segments on that
timeline as we recycle. We might be just about to reach the point
where we switch to next timeline, so might only need one more WAL
segment on the current timeline. We'll live with the waste in that
situation. Bug pointed out by Fujii Masao. 9.1 and 9.2 had the same
issue, when recovery target timeline was changed, but I committed a
slightly different version of this patch on those branches.
http://git.postgresql.org/pg/commitdiff/343ee00b730e9c422082160718b9785f0cb7f8f6

- Follow TLI of last replayed record, not recovery target TLI, in
walsenders. Most of the time, the last replayed record comes from
the recovery target timeline, but there is a corner case where it
makes a difference. When the startup process scans for a new
timeline, and decides to change recovery target timeline, there is a
window where the recovery target TLI has already been bumped, but
there are no WAL segments from the new timeline in pg_xlog yet. For
example, if we have just replayed up to point 0/30002D8, on timeline
1, there is a WAL file called 000000010000000000000003 in pg_xlog
that contains the WAL up to that point. When recovery switches
recovery target timeline to 2, a walsender can immediately try to
read WAL from 0/30002D8, from timeline 2, so it will try to open WAL
file 000000020000000000000003. However, that doesn't exist yet - the
startup process hasn't copied that file from the archive yet nor has
the walreceiver streamed it yet, so walsender fails with error
"requested WAL segment 000000020000000000000003 has already been
removed". That's harmless, in that the standby will try to reconnect
later and by that time the segment is already created, but error
messages that should be ignored are not good. To fix that, have
walsender track the TLI of the last replayed record, instead of the
recovery target timeline. That way walsender will not try to read
anything from timeline 2, until the WAL segment has been created and
at least one record has been replayed from it. The recovery target
timeline is now xlog.c's internal affair, it doesn't need to be
exposed in shared memory anymore. This fixes the error reported by
Thom Brown. depesz the same error message, but I'm not sure if this
fixes his scenario.
http://git.postgresql.org/pg/commitdiff/af275a12dfeecd621ed9899a9382f26a68310263

- Forgot to remove extern declaration of GetRecoveryTargetTLI().
Fujii Masao
http://git.postgresql.org/pg/commitdiff/d57a97343ecec89ecb7d932c21c886058ad64e6b

- Fix race condition if a file is removed while pg_basebackup is
running. If a relation file was removed when the server-side
counterpart of pg_basebackup was just about to open it to send it to
the client, you'd get a "could not open file" error. Fix that.
Backpatch to 9.1, this goes back to when pg_basebackup was
introduced.
http://git.postgresql.org/pg/commitdiff/36e4456d78b6a27cdaf82280b98998fc3bf3e9c7

- Fix sloppiness in the timeline switch over streaming replication
patch. Here's another attempt at fixing the logic that decides how
far the WAL can be streamed, which was still broken if the timeline
changed while streaming. You would get an assertion failure. The
way the logic is now written is more readable, too. Thom Brown
reported the assertion failure.
http://git.postgresql.org/pg/commitdiff/1ff92eea140ccf0503b7399549031976e5c6642e

Bruce Momjian pushed:

- Add pg_upgrade comment about mismatch error. Add comment stating
that constraint and index names must match.
http://git.postgresql.org/pg/commitdiff/345fb82f1616b4d44d8a67a6c10e964400d29c09

- Avoid using NAMEDATALEN in pg_upgrade. Because the client encoding
might not match the server encoding, pg_upgrade can't allocate
NAMEDATALEN bytes for storage of database, relation, and namespace
identifiers. Instead pg_strdup() the memory and free it. Also add
C comment in initdb.c about safe NAMEDATALEN usage.
http://git.postgresql.org/pg/commitdiff/dc9896a2457f0d72458f1ff45935362521f0f99c

Robert Haas pushed:

- Adjust many backend functions to return OID rather than void.
Extracted from a larger patch by Dimitri Fontaine. It is hoped that
this will provide infrastructure for enriching the new event trigger
functionality, but it seems possibly useful for other purposes as
well.
http://git.postgresql.org/pg/commitdiff/c504513f83a9ee8dce4a719746ca73102cae9f13

== Rejected Patches (for now) ==

No one was disappointed this week :-)

== Pending Patches ==

Jeff Davis sent in another revision of a patch to implement SP-GiST
for ranges based on 2d-mapping and quad-tree.

Alexander Korotkov sent in another revision of a patch to implement
index support for DFA regexes.

Andres Freund sent in a patch to rearrange how XLByte* is used.

Shigeru HANADA and Pavel Stehule traded patches to add \pset to psql.

Amit Kapila sent in another revision of a patch to add hooks for pre-
and post-processor executables for COPY and \copy.

KaiGai Kohei sent in another revision of a patch to add row-level
access control.

Laurenz Albe sent in a patch to fix a bug in the LDAP documentation.

Tomas Vondra sent in another revision of a patch to enable reducing
the amount of pgbench output.

Andres Freund sent in a patch to removes some of the cruft from
gram.y.

Gurjeet Singh sent in another revision of a patch to use 64-bit ints
in pgbench for performance.

Peter Eisentraut sent in a patch to improve PL/Python on OS X.

Peter Geoghegan sent in another revision of a patch to improve memory
usage in tuplesort.

Marko (johto) Tiikkaja sent in a patch to add a STRICT option to
PERFORM in PL/pgsql.

Phil Sorber sent in two more revisions of a patch to create a pg_ping
utility.

Marko Kreen sent in a patch to fix an infelicity in pgcrypto when SSL
is on.

Bruce Momjian sent in a patch to speed up pg_upgrade.

KaiGai Kohei sent in another revision of a patch to add write support
to the FDW interface.

Tomas Vondra sent in another revision of a patch to optimize droppign
multiple tables in a transaction.