Stéphane Schildknecht | 27 Jan 19:31 2015
Picon

slony1-ctl 1.3.0 released

Hello,

The slony1-ctl development team is proud to announce version 1.3.0 of
slony1-ctl, a collection of shell scripts aiming at simplifying everyday
admnistration of a Slony replication.

This version adds no new feature but compatibility with slony 2.2.
The major change is a better use of variables and a deep comments cleaning.

The project homepage :
  http://pgfoundry.org/projects/slony1-ctl/

The package may be downloaded at :
  http://pgfoundry.org/frs/download.php/3838/slony1-ctl-REL1_3_0.tar.gz

Best regards,
--

-- 
Stéphane Schildknecht
Contact régional PostgreSQL pour l'Europe francophone
Loxodata - Conseil, expertise et formations

David Fetter | 26 Jan 02:09 2015

== PostgreSQL Weekly News - January 25 2015 ==

== PostgreSQL Weekly News - January 25 2015 ==

Early Bird registration is available for PGConf.US.
http://pgconfus2015.eventbrite.com/?aff=pgann1

== PostgreSQL Product News ==

POWA 1.2.1, a PostgreSQL workload analyzer, released.
http://dalibo.github.io/powa/

Pyrseas 0.7.2, a toolkit for PostgreSQL version control, released.
https://github.com/pyrseas/Pyrseas

Slony-I 2.2.4, a trigger-based replication system for PostgreSQL, released.
http://www.slony.info/

== PostgreSQL Jobs for January ==

http://archives.postgresql.org/pgsql-jobs/2015-01/threads.php

== PostgreSQL Local ==

FOSDEM PGDay (January 30, 2015) and the FOSDEM PostgreSQL
Dev Room (January 31-February 1, 2015)
http://fosdem2015.pgconf.eu/

Prague PostgreSQL Developer Day (P2D2) 2015 will be in Prague, Czech
Republic February 11-12, 2015.
http://www.p2d2.cz/

(Continue reading)

Moshe Jacobson | 26 Jan 03:05 2015

New user group in Atlanta

To all Atlanta PostgreSQL enthusiasts,

I'm excited to announce that I have started a new user group called PostgreSQL in Atlanta. The group meets on the 2nd Wednesday of each month.

Clicking the link above will send you to the meetup.com page, where you can learn more. We already held our first meeting and it was a great success with 8 attendees and some great ideas. If you live in Atlanta, I hope to see you at the next one!

Moshe Jacobson
Principal Architect, Nead Werx Inc.
2323 Cumberland Parkway · Suite 201 · Atlanta, GA 30339

"Quality is not an act, it is a habit." -- Aristotle
Gabriele Bartolini | 26 Jan 10:26 2015
Picon

Barman 1.4.0 released

26 January 2015: 2ndQuadrant is proud to announce the release of
version 1.4.0 of Barman, Backup and Recovery Manager for PostgreSQL.

This major release features file-level incremental backup, a kind of
full periodic backup which saves only data changes from the latest
full backup available in the catalogue for a specific PostgreSQL
server. Depending on the context and the database workload, the data
deduplication ratio might easily reach 50-70% per full backup,
leading to significant reductions in both backup time and disk space.

PostgreSQL 9.4 users will transparently benefit from the integration
of Barman with pg_stat_archiver view. In particular, any continuous
archiving problem will be immediately spotted by the barman check
command directly on the source.

Management of WAL files has been improved, by optimising the
calculation of WAL statistics, tying archiving with backup and by
distinctively managing WAL trashing for exclusive and concurrent
backups.

Relevant efforts in unit testing have made the code more robust.
Minor bugs have also been fixed.

Many thanks for funding towards the development of this release go to
BIJ12 (www.bij12.nl), Jobrapido (www.jobrapido.com), Navionics (
www.navionics.com), Sovon Vogelonderzoek Nederland (www.sovon.nl),
and Subito.it (www.subito.it).

For a complete list of changes, see the "Release Notes" section
below.

Incremental backup. Incremental backup is a kind of full periodic
backup which saves only data changes from the latest full backup
available in the catalogue for a specific PostgreSQL server. The main
goals of incremental backup in Barman are:

  * Reduce the time taken for the full backup process
  * Reduce the disk space occupied by several periodic backups (data
    deduplication)

This feature heavily relies on rysnc and hard links, which must be
therefore supported by both the underlying operating system and the
file system where the backup data resides.

The main concept is that two periodic base backups will share those
files that have not changed, leading to relevant savings in disk
usage. This is particularly true of VLDB contexts and, more in
general, of those databases containing a high percentage of read-only
historical tables. Barman implements incremental backup through a
global/server option, called reuse_backup, that transparently manages
the barman backup command. Behaviour can also be changed at runtime
through the --reuse-backup runtime option for the barman backup
command.

Links

  * Man page, section 1: http://docs.pgbarman.org/barman.1.html
  * Man page, section 5: http://docs.pgbarman.org/barman.5.html
  * pgespresso extension: https://github.com/2ndquadrant-it/
    pgespresso

Release notes

  * Incremental base backup implementation through the reuse_backup
    global/server option. Possible values are off (disabled,
    default), copy (preventing unmodified files from being
    transferred) and link (allowing for deduplication through hard
    links).
  * Store and show deduplication effects when using reuse_backup=
    link.
  * Added transparent support of pg_stat_archiver (PostgreSQL 9.4) in
    check, show-server and status commands.
  * Improved administration by invoking WAL maintenance at the end of
    a successful backup.
  * Changed the way unused WAL files are trashed, by differentiating
    between concurrent and exclusive backup cases.
  * Improved performance of WAL statistics calculation.
  * Treat a missing pg_ident.conf as a WARNING rather than an error.
  * Refactored output layer by removing remaining yield calls.
  * Check that rsync is in the system path.
  * Include history files in WAL management.
  * Improved robustness through more unit tests.
  * Fixed bug #55: Ignore fsync EINVAL errors on directories.
  * Fixed bug #58: retention policies delete.

Download

    1.4.0/
    barman-1.4.0.tar.gz/download
  * RPMs for RHEL/CentOS 5: http://sourceforge.net/projects/pgbarman/
    files/1.4.0/barman-1.4.0-1.rhel5.noarch.rpm/download
    rhel5-deps/)
  * RPMs for RHEL/CentOS 6: http://sourceforge.net/projects/pgbarman/
    files/1.4.0/barman-1.4.0-1.rhel6.noarch.rpm/download
    rhel6-deps/)
  * pgespresso on PostgreSQL Extension framework (PGXN): http://
  * pgespresso RPM/Debian packages: https://sourceforge.net/projects/
    pgbarman/files/pgespresso/
  * Online documentation: http://www.pgbarman.org/documentation
    /1.4.0/barman-tutorial.en.pdf/download

About: Barman (Backup and Recovery Manager) is an open source
administration tool for disaster recovery of PostgreSQL servers
written in Python. It allows your organisation to perform remote
backups of multiple servers in business critical environments and
help DBAs during the recovery phase. Barman’s most requested features
include backup catalogues, incremental backup, retention policies,
remote backup and recovery, archiving and compression of WAL files
and backups. Barman is distributed under GNU GPL 3.

--
 Gabriele Bartolini - 2ndQuadrant Italia - Managing Director
 PostgreSQL Training, Services and Support
 gabriele.bartolini <at> 2ndQuadrant.it | www.2ndQuadrant.it
Magnus Hagander | 26 Jan 10:29 2015
Picon

Nordic PGDay 2015 - registration open and schedule posted

Nordic PGDay 2015 will be held in Copenhagen, Denmark, at the
Radisson Blu Falconer hotel in Fredriksberg, on March 11.
It will feature a full day with a single track of PostgreSQL
presentations from both Nordic and global PostgreSQL experts,
covering a wide range of topics.
 
The schedule has now been posted, and is available at
 
We have also opened up registration for the event. Early bird
registration (before Feb 11th or the first 40 registrations)
costs €40, and normal registration costs €60. There is a limited
number of seats available, so we suggest you register early to
make sure you get a seat.
 
Registration is available at http://2015.nordicpgday.org/registration/.
 
We also still have openings for Supporter sponsorship, which
includes free entrance to the conference. For more information
and instant sign-up, see http://2015.nordicpgday.org/sponsors/.
 
We look forward to seeing you in Copenhagen in March!
Joe Abbate | 23 Jan 20:05 2015

Pyrseas 0.7.2 is now available

A maintenance release of Pyrseas 0.7, a framework for
upgrading/migrating a Postgres database, has been released.  Release
0.7.2 available from:

   GitHub:     https://github.com/perseas/Pyrseas
   PyPI:       https://pypi.python.org/pypi/Pyrseas
   PGXN:       http://pgxn.org/dist/pyrseas/
   PgFoundry:  http://pgfoundry.org/projects/pyrseas

Updated documentation is viewable at:

   Read the Docs:  http://pyrseas.readthedocs.org/en/r0.7/
   Python Hosted:  http://pythonhosted.org/Pyrseas/

This release fixes various issues, including:

 - Do not error on tables whose names start with 'public' (#109)

 - Deal properly with inherited constraints in children tables (#102)

 - Handle external languages like plv8 correctly (#97)

 - Correct quoting of mixed case constraint names (#83)

 - Avoid problems with certain complex index definitions (#98)

 - Have dbtoyaml output correctly a table with an embedded period in
    the name and having an associated sequence (#79)

 - Use relative paths in database summary for --multiple-files
    (#93)

 - Support mapping of indexes on materialized views (#82)

All users are encouraged to upgrade, e.g., pip install --upgrade,
at the earliest convenience.

Joe Abbate

--

-- 
Sent via pgsql-announce mailing list (pgsql-announce <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-announce

Jonathan S. Katz | 23 Jan 05:49 2015
Picon

PGConf US 2015 Schedule & Early-Bird Registration Open

Debates abounded; coffee drunk; phone calls made at 8:30am on Saturday mornings; reporting queries run
(of course in PostgreSQL).  After reviewing 107 submissions, we are pleased to announce the PGConf US 2015
official schedule:

	http://www.pgconf.us/2015/schedule/

PGConf US 2015 is taking place in New York City from March 25-27 at the New York Marriott Downtown.  We are
offering a day of trainings on March 25 in addition to the First Annual Regulated Industry Summit (more
info on both at http://www.pgconf.us/2015/training/) as well as our regular sessions on March 26-27.

There are so many cool sessions (in fact, we added on another track!) that it is hard to highlight
everything, but here is a small glimpse of what to expect:

	* Large-scale PostgreSQL deployment case-studies from organizations such as TripAdvisor, Braintree,
Children's Hospital of Philadelphia, Zalando, Stony Brook Medicine, and more
  	* Theory and applications of those cutting-edge PostgreSQL features, such as JSONB, logical
replication, row-level security, and BDR
	* Analyzing all of the latest PostgreSQL deployment options, from bare metal to cloud-based infrastructures
	* A "PostGIS Track" on March 26, featuring key contributors from the PostGIS & PostgreSQL community
	* How to optimize every single I/O op with talks from preeminent PostgreSQL performance experts
	* ...and why not "Fight for Small Data" with a variety of strategy talks

Our early-bird registration is open and tickets at the early bird rate are available through February 1,
2015.  Tickets can be purchased directly from here:

	http://pgconfus2015.eventbrite.com/?aff=pgann1

PGConf US 2015 is hosted by the United States PostgreSQL Association (http://www.postgresql.us), a
nonprofit 501(c)(3) created to support PostgreSQL in the United States through user group development,
conferences, educational initiatives, and fun.  We would not be able to produce PGConf US without the
generous support of our sponsors.  We would like to highlight our Platinum and Gold sponsors:

	Platinum: EnterpriseDB, 2ndQuadrant, Citus Data
	Gold: Amazon Web Services

For more information, please visit http://www.pgconf.us/

We look forward to hosting you in March!

--

-- 
Sent via pgsql-announce mailing list (pgsql-announce <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-announce

Julien Rouhaud | 19 Jan 19:27 2015

PoWA 1.2.1 released

PoWA 1.2.1 released
===================

Paris, Jan. 19 2015

DALIBO is proud to present a new release of PoWA, a performance tool for
PostgreSQL.

Please also note that the project has a new dedicated mailing list,
available at powa-users <at> googlegroups.com
(https://groups.google.com/forum/?hl=fr#!forum/powa-users). Feel free to
join and ask any question.

Realtime traffic analysis and dynamic graphs
--------------------------------------------

PoWA is a workload analyzer that gives a clear view of the current
activity of your PostgreSQL servers with a query runtime graph and a
block hit/read graph along with a chart of time consuming requests over
the specified time period.

If you zoom anywhere in one of the graphs, the chart will adjust and
show you which queries were running at that time. If you click on a
specific query, you will get additional graphs such as read/write time,
number of rows affected, local and shared hit, etc.

A bunch of PL functions are also available to access and manage the stats.

New features and changed in UI
------------------------------

  - UI is now compatible with mojolicious 5.0 and more
  - UI can now connect to multiple servers, and credentials can be
specified for each server
  - The timestamps are now displayed in ISO 8601 format
  - POWA_CONFIG_FILE variable has been added to allow a specific config
file location and/or name
  - Better charts display on smaller screens

Credits
-------

DALIBO would like to thank the users and developpers who contributed to
this release, especially Ahmed Bessifi and Luis Pinto Da Costa.

PoWA is an open project available under the PostgreSQL License. Any
contribution to build a better tool is welcome. You just have to send
your ideas, features requests or patches using the GitHub tools or to
powa-users <at> googlegroups.com
(https://groups.google.com/forum/?hl=fr#!forum/powa-users)

Links
-----

  - Download : http://dalibo.github.io/powa/
  - Demo : http://demo-powa.dalibo.com (login/pass = powa/demo)

About PoWA
----------

PoWA is PostgreSQL Workload Analyzer that gathers performance stats and
provides real-time charts and graph to help monitor and tune your
PostgreSQL servers. It is similar to Oracle AWR or SQL Server MDW.

Code & Demo at http://dalibo.github.io/powa/

About DALIBO
------------

DALIBO is the leading PostgreSQL company in France, providing support,
trainings and consulting to its customers since 2005. The company
contributes to the PostgreSQL community in various ways, including :
code, articles, translations, free conferences and workshops.

Check out DALIBO's open source projects at http://dalibo.github.io

-- 
Julien Rouhaud
http://dalibo.com - http://dalibo.org

--

-- 
Sent via pgsql-announce mailing list (pgsql-announce <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-announce

David Fetter | 19 Jan 08:15 2015

== PostgreSQL Weekly News - January 18 2015 ==

== PostgreSQL Weekly News - January 18 2015 ==

Giulio Calacoci, the main developer of Barman, will host a the
"Discover Barman 1.4.0" meetup in Prato, Italy next February 6th.
Further information and registration:
http://www.meetup.com/2ndQuadrant-Italia-PostgreSQL-Meetup/events/219801332/

The CfP for the second Swiss Postgres Conference, to be held June
25-26, 2015 at HSR Rapperswil, is open until April 1.
http://www.postgres-conference.ch/cfp/

== PostgreSQL Product News ==

pgmp 1.0.2, a high-precision integer and rational arithmetic library
exposing GMP, released.  Details and download below:
http://pgmp.projects.pgfoundry.org/
http://pgxn.org/dist/pgmp/

== PostgreSQL Jobs for January ==

http://archives.postgresql.org/pgsql-jobs/2015-01/threads.php

== PostgreSQL Local ==

PGCon 2015 (June 16-20) call for papers is out.  Talk submission ends
January 19, 2014.  Details at
http://www.pgcon.org/2015/papers.php

FOSDEM PGDay (January 30, 2015) and the FOSDEM PostgreSQL
Dev Room (January 31-February 1, 2015)
http://fosdem2015.pgconf.eu/

Prague PostgreSQL Developer Day (P2D2) 2015 will be in Prague, Czech
Republic February 11-12, 2015.
http://www.p2d2.cz/

The Melbourne PostgreSQL meetup on February 18, 2015 will be hosting
Gabriele Bartolini on PostgreSQL 9.4 for devops.  Details below, and
R, SVP.
http://www.meetup.com/melpug/events/219082475/

pgDaySF 2015 will be held March 10, 2015 in Burlingame, California.
http://sfpostgres.org/pgday-sf-2015-call-for-speakers-and-sponsors/

The CfP is open for Nordic PostgreSQL Day 2015, which will be held
March 11, 2015 in  Copenhagen, Denmark.
http://2015.nordicpgday.org/cfp/

The CfP for PGConf US 2015 is open through December 17th, 2014
Notifications will go out on January 10, 2014.  The event takes place
March 25-27, 2015 in NYC.
http://nyc.pgconf.us/2015/

== 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.org, German language
to pwn <at> pgug.de, Italian language to pwn <at> itpug.org.  Spanish language
to pwn <at> arpug.com.ar.

== Applied Patches ==

Stephen Frost pushed:

- Skip dead backends in MinimumActiveBackends.  Back in ed0b409,
  PGPROC was split and moved to static variables in procarray.c, with
  procs in ProcArrayStruct replaced by an array of integers
  representing process numbers (pgprocnos), with -1 indicating a dead
  process which has yet to be removed.  Access to procArray is
  generally done under ProcArrayLock and therefore most code does not
  have to concern itself with -1 entries.  However,
  MinimumActiveBackends intentionally does not take ProcArrayLock,
  which means it has to be extra careful when accessing procArray.
  Prior to ed0b409, this was handled by checking for a NULL in the
  pointer array, but that check was no longer valid after the split.
  Coverity pointed out that the check could never happen and so it was
  removed in 5592eba.  That didn't make anything worse, but it didn't
  fix the issue either.  The correct fix is to check for pgprocno ==
  -1 and skip over that entry if it is encountered.  Back-patch to
  9.2, since there can be attempts to access the arrays prior to their
  start otherwise.  Note that the changes prior to 9.4 will look a bit
  different due to the change in 5592eba.  Note that
  MinimumActiveBackends only returns a bool for heuristic purposes and
  any pre-array accesses are strictly read-only and so there is no
  security implication and the lack of fields complaints indicates
  it's very unlikely to run into issues due to this.  Pointed out by
  Noah Misch.
  http://git.postgresql.org/pg/commitdiff/1bf4a84d0f9f7a442790d7948e96cd42eeb90a91

Tom Lane pushed:

- Use correct text domain for errcontext() appearing within ereport().
  The mechanism added in commit
  dbdf9679d7d61b03a3bf73af9b095831b7010eb5 for associating the correct
  translation domain with errcontext strings potentially fails in
  cases where errcontext() is used within an ereport() macro.  Such
  usage was not originally envisioned for errcontext(), but we do have
  a few places that do it.  In this situation, the intended comma
  expression becomes just a couple of arguments to errfinish(), which
  the compiler might choose to evaluate right-to-left.  Fortunately,
  in such cases the textdomain for the errcontext string must be the
  same as for the surrounding ereport.  So we can fix this by letting
  errstart initialize context_domain along with domain; then it will
  have the correct value no matter which order the calls occur in.
  (Note that error stack callback functions are not invoked until
  errfinish, so normal usage of errcontext won't affect what happens
  for errcontext calls within the ereport macro.) In passing, make
  sure that errcontext calls within the main backend set
  context_domain to something non-NULL.  This isn't a live bug because
  NULL would select the current textdomain() setting which should be
  the right thing anyway --- but it seems better to handle this
  completely consistently with the regular domain field.  Per report
  from Dmitry Voronin.  Backpatch to 9.3; before that, there wasn't
  any attempt to ensure that errcontext strings were translated in an
  appropriate domain.
  http://git.postgresql.org/pg/commitdiff/1f9bf05e539646103c518bcbb49c04919b238f7a

- Avoid unexpected slowdown in vacuum regression test.  I noticed the
  "vacuum" regression test taking really significantly longer than it
  used to on a slow machine.  Investigation pointed the finger at
  commit e415b469b33ba328765e39fd62edcd28f30d9c3c, which added
  creation of an index using an extremely expensive index function.
  That function was evidently meant to be applied only twice ... but
  the test re-used an existing test table, which up till a couple
  lines before that had had over two thousand rows.  Depending on
  timing of the concurrent regression tests, the intervening VACUUMs
  might have been unable to remove those recently-dead rows, and then
  the index build would need to create index entries for them too,
  leading to the wrap_do_analyze() function being executed 2000+ times
  not twice.  Avoid this by using a different table that is guaranteed
  to have only the intended two rows in it.  Back-patch to 9.0, like
  the commit that created the problem.
  http://git.postgresql.org/pg/commitdiff/5b3ce2c911a2ec9de13b0dea7e135ad945a14583

- Fix some functions that were declared static then defined
  not-static.  Per testing with a compiler that whines about this.
  http://git.postgresql.org/pg/commitdiff/7391e2513f486a5df3eebf132c6dd6c16cf4e1f1

- Remove duplicate specification of -Ae for HP-UX C compiler.
  Autoconf has known about automatically selecting -Ae when needed for
  quite some time now, so remove the redundant addition in
  template/hpux.  Noted while setting up buildfarm member pademelon.
  http://git.postgresql.org/pg/commitdiff/fd3d894e4ea0021efa2628e4dfc5fe0ed3071859

- Allow CFLAGS from configure's environment to override automatic
  CFLAGS.  Previously, configure would add any switches that it chose
  of its own accord to the end of the user-specified CFLAGS string.
  Since most compilers process these left-to-right, this meant that
  configure's choices would override the user-specified flags in case
  of conflicts.  We'd rather that worked the other way around, so
  adjust the logic to put the user's string at the end not the
  beginning.  There does not seem to be a need for a similar behavior
  change for CPPFLAGS or LDFLAGS: in those, the earlier switches tend
  to win (think -I or -L behavior) so putting the user's string at the
  front is fine.  Backpatch to 9.4 but not earlier.  I'm not planning
  to run buildfarm member guar on older branches, and it seems a bit
  risky to change this behavior in long-stable branches.
  http://git.postgresql.org/pg/commitdiff/85a2a8903f7e9151793308d0638621003aded5ae

- Improve performance of EXPLAIN with large range tables.  As of 9.3,
  ruleutils.c goes to some lengths to ensure that table and column
  aliases used in its output are unique.  Of course this takes more
  time than was required before, which in itself isn't fatal.
  However, EXPLAIN was set up so that recalculation of the unique
  aliases was repeated for each subexpression printed in a plan.  That
  results in O(N^2) time and memory consumption for large plan trees,
  which did not happen in older branches.  Fortunately, the expensive
  work is the same across a whole plan tree, so there is no need to
  repeat it; we can do most of the initialization just once per query
  and re-use it for each subexpression.  This buys back most (not all)
  of the performance loss since 9.2.  We need an extra ExplainState
  field to hold the precalculated deparse context.  That's no problem
  in HEAD, but in the back branches, expanding sizeof(ExplainState)
  seems risky because third-party extensions might have local
  variables of that struct type.  So, in 9.4 and 9.3, introduce an
  auxiliary struct to keep sizeof(ExplainState) the same.  We should
  refactor the APIs to avoid such local variables in future, but
  that's material for a separate HEAD-only commit.  Per gripe from
  Alexey Bashtanov.  Back-patch to 9.3 where the issue was introduced.
  http://git.postgresql.org/pg/commitdiff/a5cd70dcbc268381e13cb0b2973b5732856d186f

- Rearrange explain.c's API so callers need not embed
  sizeof(ExplainState).  The folly of the previous arrangement was
  just demonstrated: there's no convenient way to add fields to
  ExplainState without breaking ABI, even if callers have no need to
  touch those fields.  Since we might well need to do that again
  someday in back branches, let's change things so that only explain.c
  has to have sizeof(ExplainState) compiled into it.  This costs one
  extra palloc() per EXPLAIN operation, which is surely pretty
  negligible.
  http://git.postgresql.org/pg/commitdiff/8e166e164c7c4531d7eb150d836aa2357989237a

- Fix use-of-already-freed-memory problem in EvalPlanQual processing.
  Up to now, the "child" executor state trees generated for
  EvalPlanQual rechecks have simply shared the ResultRelInfo arrays
  used for the original execution tree.  However, this leads to
  dangling-pointer problems, because ExecInitModifyTable() is all too
  willing to scribble on some fields of the ResultRelInfo(s) even when
  it's being run in one of those child trees.  This trashes those
  fields from the perspective of the parent tree, because even if the
  generated subtree is logically identical to what was in use in the
  parent, it's in a memory context that will go away when we're done
  with the child state tree.  We do however want to share information
  in the direction from the parent down to the children; in
  particular, fields such as es_instrument *must* be shared or we'll
  lose the stats arising from execution of the children.  So the
  simplest fix is to make a copy of the parent's ResultRelInfo array,
  but not copy any fields back at end of child execution.  Per report
  from Manuel Kniep.  The added isolation test is based on his
  example.  In an unpatched memory-clobber-enabled build it will
  reliably fail with "ctid is NULL" errors in all branches back to
  9.1, as a consequence of junkfilter->jf_junkAttNo being overwritten
  with $7f7f.  This test cannot be run as-is before that for lack of
  WITH syntax; but I have no doubt that some variant of this problem
  can arise in older branches, so apply the code change all the way
  back.
  http://git.postgresql.org/pg/commitdiff/c480cb9d246cec5e1dd7d72956e792df16e5445d

- Improve new caching logic in tbm_add_tuples().  For no significant
  extra complexity, we can cache knowledge that the target page is
  lossy, and save a hash_search per iteration in that case as well.
  This probably makes little difference, since the extra rechecks that
  must occur when pages are lossy are way more expensive than anything
  we can save here ... but we might as well do it if we're going to
  cache anything.
  http://git.postgresql.org/pg/commitdiff/779fdcdeeeb9cdbfd271f8dc5bde76ed0c7b0813

- Show sort ordering options in EXPLAIN output.  Up to now, EXPLAIN
  has contented itself with printing the sort expressions in a Sort or
  Merge Append plan node.  This patch improves that by annotating the
  sort keys with COLLATE, DESC, USING, and/or NULLS FIRST/LAST
  whenever nondefault sort ordering options are used.  The output is
  now a reasonably close approximation of an ORDER BY clause
  equivalent to the plan's ordering.  Marius Timmer, Lukas Kreft, and
  Arne Scheffer; reviewed by Mike Blackwell.  Some additional hacking
  by me.
  http://git.postgresql.org/pg/commitdiff/20af53d7191f84d0f5b86da4362e481b7e85d52a

- Fix ancient thinko in default table rowcount estimation.  The code
  used sizeof(ItemPointerData) where sizeof(ItemIdData) is correct,
  since we're trying to account for a tuple's line pointer.  Spotted
  by Tomonari Katsumata (bug #12584).  Although this mistake is of
  very long standing, no back-patch, since it's a relatively harmless
  error and changing it would risk changing default planner behavior
  in stable branches.  (I don't see any change in regression test
  outputs here, but the buildfarm may think differently.)
  http://git.postgresql.org/pg/commitdiff/75df6dc083f7a989697b5002a421fb204f2eeddb

Álvaro Herrera pushed:

- Fix get_object_address argument type for extension statement.
  Commit 3f88672a4 neglected to update the AlterExtensionContentsStmt
  production in the grammar to use TypeName to represent types when
  passing objects to get_object_address.  Reported as a pg_upgrade
  failure by Jeff Janes.
  http://git.postgresql.org/pg/commitdiff/5c5ffee80f3547625021c29f45b37321d8c710bf

- Tweak heapam's rmgr desc output slightly.  Some spaces were missing,
  and putting the affected tuple offset first in the lock cases
  instead of the locking data makes more sense.  No backpatch since
  this is cosmetic and surrounding code has changed.
  http://git.postgresql.org/pg/commitdiff/d126e1e95fab44cc73002de3eaa08e2d88f11c50

Heikki Linnakangas pushed:

- Fix typos in comment.  Plus some tiny wordsmithing of
  not-quite-typos.
  http://git.postgresql.org/pg/commitdiff/3dfce37627b76e4da9e1d6090beedb608cefafcb

- Silence Coverity warnings about unused return values from
  pushJsonbValue().  Similar warnings from backend were silenced
  earlier by commit c8315930, but there were a few more
  contrib/hstore.  Michael Paquier
  http://git.postgresql.org/pg/commitdiff/e37d474f91c3a8a88be28a65389c948a55f18075

- Fix thinko in re-setting wal_log_hints flag from a parameter-change
  record.  The flag is supposed to be copied from the record. Same
  issue with track_commit_timestamps, but that's master-only.  Report
  and fix by Petr Jalinek. Backpatch to 9.4, where wal_log_hints was
  added.
  http://git.postgresql.org/pg/commitdiff/49b04188f83fb8cacf925978989bc20399e76786

- Another attempt at fixing Windows Norwegian locale.  Previous fix
  mapped "Norwegian (Bokmål)" locale, which contains a non-ASCII
  character, to the pure ASCII alias "norwegian-bokmal". However, it
  turns out that more recent versions of the CRT library, in
  particular MSVCR110 (Visual Studio 2012), changed the behaviour of
  setlocale() so that if you pass "norwegian-bokmal" to setlocale, it
  returns "Norwegian_Norway".  That meant trouble, when setlocale(...,
  NULL) first returned "Norwegian (Bokmål)_Norway", which we mapped to
  "norwegian-bokmal_Norway", but another call to setlocale(...,
  "norwegian-bokmal_Norway") returned "Norwegian_Norway". That caused
  PostgreSQL to think that they are different locales, and therefore
  not compatible. That caused initdb to fail at CREATE DATABASE.
  Older CRT versions seem to accept "Norwegian_Norway" too, so change
  the mapping to return "Norwegian_Norway" instead of
  "norwegian-bokmal".  Backpatch to 9.2 like the previous attempt. We
  haven't made a release that includes the previous fix yet, so we
  don't need to worry about changing the locale of existing clusters
  from "norwegian-bokmal" to "Norwegian_Norway".  (Doing any mapping
  like this at all requires changing the locale of existing databases;
  the release notes need to include instructions for that).
  http://git.postgresql.org/pg/commitdiff/aa1d2fc5e91e396bec5bf8a8d10b6cc4af0b0fff

- Advance backend's advertised xmin more aggressively.  Currently, a
  backend will reset it's PGXACT->xmin value when it doesn't have any
  registered snapshots left. That covered the common case that a
  transaction in read committed mode runs several queries, one after
  each other, as there would be no snapshots active between those
  queries.  However, if you hold cursors across each of the query, we
  didn't get a chance to reset xmin.  To make that better, keep all
  the registered snapshots in a pairing heap, ordered by xmin so that
  it's always quick to find the snapshot with the smallest xmin. That
  allows us to advance PGXACT->xmin whenever the oldest snapshot is
  deregistered, even if there are others still active.  Per discussion
  originally started by Jeff Davis back in 2009 and more recently by
  Robert Haas.
  http://git.postgresql.org/pg/commitdiff/94028691609f8e148bd4ce72c46163f018832a5b

Andres Freund pushed:

- Allow latches to wait for socket writability without waiting for
  readability.  So far WaitLatchOrSocket() required to pass in
  WL_SOCKET_READABLE as that solely was used to indicate error
  conditions, like EOF. Waiting for WL_SOCKET_WRITEABLE would have
  meant to busy wait upon socket errors.  Adjust the API to signal
  errors by returning the socket as readable, writable or both,
  depending on WL_SOCKET_READABLE/WL_SOCKET_WRITEABLE being specified.
  It would arguably be nicer to return WL_SOCKET_ERROR but that's not
  possible on platforms and would probably also result in more complex
  callsites.  This previously had explicitly been forbidden in
  e42a21b9e6c9, as there was no strong use case at that point. We now
  are looking into making FE/BE communication use latches, so changing
  this makes sense.  There also are some portability concerns because
  there cases of older platforms where select(2) is known to, in
  violation of POSIX, not return a socket as writable after the peer
  has closed it.  So far the platforms where that's the case provide a
  working poll(2). If we find one where that's not the case, we'll
  need to add a workaround for that platform.  Discussion:
  20140927191243.GD5423 <at> alap3.anarazel.de Reviewed-By: Heikki
  Linnakangas, Noah Misch
  http://git.postgresql.org/pg/commitdiff/4bad60e3fd9a5fc6070fd4d1bd820a280e174654

- Add barriers to the latch code.  Since their introduction latches
  have required barriers in SetLatch and ResetLatch - but when they
  were introduced there wasn't any barrier abstraction. Instead
  latches were documented to rely on the callsites to provide barrier
  semantics.  Now that the barrier support looks halfway complete, add
  the necessary barriers to both latch implementations.  Also remove a
  now superflous lock acquisition from syncrep.c and a superflous (and
  insufficient) barrier from freelist.c. There might be other cases
  that can now be simplified, but those are the only ones I've seen on
  a quick scan.  We might want to backpatch this at some later point,
  but right now the barrier infrastructure in the backbranches isn't
  totally on par with master.  Discussion:
  20150112154026.GB2092 <at> awork2.anarazel.de
  http://git.postgresql.org/pg/commitdiff/14e8803f101a54d99600683543b0f893a2e3f529

- Remove some dead IsUnderPostmaster code from bootstrap.c.  Since
  commit 626eb021988a2 has introduced the auxiliary process
  infrastructure, bootstrap_signals() was never used when forked from
  postmaster.  Remove the IsUnderPostmaster specific code, and add a
  appropriate assertion.
  http://git.postgresql.org/pg/commitdiff/0139dea8f1cea49f13c22a3f645dbdd02b90d25c

- Commonalize process startup code.  Move common code, that was
  duplicated in every postmaster child/every standalone process, into
  two functions in miscinit.c.  Not only does that already result in a
  fair amount of net code reduction but it also makes it much easier
  to remove more duplication in the future. The prime motivation
  wasn't code deduplication though, but easier addition of new common
  code.
  http://git.postgresql.org/pg/commitdiff/31c453165b5a656044ce1dbce89f5828c1c7e23c

- Make logging_collector=on work with non-windows EXEC_BACKEND again.
  Commit b94ce6e80 reordered postmaster's startup sequence so that the
  tempfile directory is only cleaned up after all the necessary state
  for pg_ctl is collected.  Unfortunately the chosen location is after
  the syslogger has been started; which normally is fine, except for
  !WIN32 EXEC_BACKEND builds, which pass information to children via
  files in the temp directory.  Move the call to RemovePgTempFiles()
  to just before the syslogger has started. That's the first child we
  fork.  Luckily EXEC_BACKEND is pretty much only used by endusers on
  windows, which has a separate method to pass information to
  children. That means the real world impact of this bug is very
  small.  Discussion: 20150113182344.GF12272 <at> alap3.anarazel.de
  Backpatch to 9.1, just as the previous commit was.
  http://git.postgresql.org/pg/commitdiff/2be82dcf17a18511df5153bcafe67a9c1387be1e

- Add a default local latch for use in signal handlers.  To do so,
  move InitializeLatchSupport() into the new common process
  initialization functions, and add a new global variable MyLatch.
  MyLatch is usable as soon InitPostmasterChild() has been called
  (i.e. very early during startup). Initially it points to a process
  local latch that exists in all processes.
  InitProcess/InitAuxiliaryProcess then replaces that local latch with
  PGPROC->procLatch. During shutdown the reverse happens.  This is
  primarily advantageous for two reasons: For one it simplifies
  dealing with the shared process latch, especially in signal
  handlers, because instead of having to check for MyProc, MyLatch can
  be used unconditionally. For another, a later patch that makes
  FEs/BE communication use latches, now can rely on the existence of a
  latch, even before having gone through InitProcess.  Discussion:
  20140927191243.GD5423 <at> alap3.anarazel.de
  http://git.postgresql.org/pg/commitdiff/59f71a0d0b56b2df48db4bf1738aece5551f7a47

- Blindly try to fix a warning in s_lock.h when compiling with gcc on
  HPPA.  The possibly, depending on compiler settings, generated
  warning was "warning: `S_UNLOCK' redefined".  The hppa spinlock
  implementation doesn't follow the rules of s_lock.h and provides a
  gcc specific implementation outside of the the part of the file
  that's supposed to do that.  It does so to avoid duplication between
  the HP compiler and gcc. That unfortunately means that S_UNLOCK is
  already defined when the HPPA specific section is reached.  Undefine
  the generic fallback S_UNLOCK definition inside the HPPA section.
  That's far from pretty, but has the big advantage of being simple.
  If somebody is interested to fix this in a prettier way...  This
  presumably got broken in the course of 0709b7ee72.  Discussion:
  20150114225919.GY5245 <at> awork2.anarazel.de Per complaint from Tom
  Lane.
  http://git.postgresql.org/pg/commitdiff/6cfd5086e140b365086d61f25c519d046dfcf7f0

- Make tbm_add_tuples more efficient by caching the last acccessed
  page.  When adding a large number of tuples to a TID bitmap using
  tbm_add_tuples() sometimes a lot of time was spent looking up a
  page's entry in the bitmap's internal hashtable.  Improve efficiency
  by caching the last accessed page, while iterating over the passed
  in tuples, hoping consecutive tuples will often be on the same page.
  In many cases that's a good bet, and in the rest the added overhead
  isn't big.  Discussion: 54479A85.8060309 <at> sigaev.ru Author: Teodor
  Sigaev Reviewed-By: David Rowley
  http://git.postgresql.org/pg/commitdiff/f5ae3ba4828ece02bae2d16b4cbce847fbcea850

- Replace walsender's latch with the general shared latch.  Relying on
  the normal shared latch simplifies interrupt/signal handling because
  we can rely on all signal handlers setting the proc latch. That in
  turn allows us to avoid the use of ImmediateInterruptOK, which
  arguably isn't correct because WaitLatchOrSocket isn't declared to
  be immediately interruptible.  Also change sections that wait on the
  walsender's latch to notice interrupts quicker/more reliably and
  make them more consistent with each other.  This is part of a larger
  "get rid of ImmediateInterruptOK" series.  Discussion:
  20150115020335.GZ5245 <at> awork2.anarazel.de
  http://git.postgresql.org/pg/commitdiff/ff44fba46c09c37dd9e60da1cb0b3a9339eb085f

- Fix use of already freed memory when dumping a database's security
  label.  pg_dump.c:dumDatabase() called ArchiveEntry() with the
  results of a a query that was PQclear()ed a couple lines earlier.
  Backpatch to 9.2 where security labels for shared objects where
  introduced.
  http://git.postgresql.org/pg/commitdiff/525b84c576e119de7f2b0d00e3a99d559771aa7b

Robert Haas pushed:

- vacuumlo: Avoid unlikely memory leak.  Spotted by Coverity.  This
  isn't likely to matter in practice, but there's no harm in fixing
  it.  Michael Paquier
  http://git.postgresql.org/pg/commitdiff/4a0a5f21fa05070295557ad6ac9b9bbe247938ad

- docs: Add missing <literal> markup.  Michael Paquier
  http://git.postgresql.org/pg/commitdiff/73a8f5176ad980d1d2c265649757af3391079318

- pg_standby: Avoid writing one byte beyond the end of the buffer.
  Previously, read() might have returned a length equal to the buffer
  length, and then the subsequent store to buf[len] would write a
  zero-byte one byte past the end.  This doesn't seem likely to be a
  security issue, but there's some chance it could result in
  pg_standby misbehaving.  Spotted by Coverity; patch by Michael
  Paquier, reviewed by me.
  http://git.postgresql.org/pg/commitdiff/0b49642b99ca2818bb8bfcaddf522b2e36a5b350

Noah Misch pushed:

- Update "pg_regress --no-locale" for Darwin and Windows.  Commit
  894459e59ffa5c7fee297b246c17e1f72564db1d revealed this option to be
  broken for NLS builds on Darwin, but "make -C contrib/unaccent
  check" and the buildfarm client rely on it.  Fix that configuration
  by redefining the option to imply LANG=C on Darwin.  In passing, use
  LANG=C instead of LANG=en on Windows; since only postmaster startup
  uses that value, testers are unlikely to notice the change.
  Back-patch to 9.0, like the predecessor commit.
  http://git.postgresql.org/pg/commitdiff/28df6a0df0a78360629163c3df5b073ea6deeca6

- Activate low-volume optional logging during regression test runs.
  Elaborated from an idea by Andres Freund.
  http://git.postgresql.org/pg/commitdiff/4c34dcf97f70fa5c3d5fbf70caff12032a27a7dd

Peter Eisentraut pushed:

- Install shared libraries also in bin on cygwin, mingw.  This was
  previously only done for libpq, not it's done for all shared
  libraries.  Reviewed-by: Michael Paquier <michael.paquier <at> gmail.com>
  http://git.postgresql.org/pg/commitdiff/cb4a3b0410d3ba19e4524fceee99fb9b10a5e08a

== Rejected Patches (for now) ==

No one was disappointed this week :-)

== Pending Patches ==

Michael Paquier sent in three revisions of a patch to remove unused
variables in hstore_to_jsonb.

Petr (PJMODOS) Jelinek sent in another revision of a patch to
implement a sequence access method.

Dean Rasheed sent in three more revisions of a patch to fix some
infelicities between INSERT...ON CONFLICT and RLS.

Michael Paquier sent in two more revisions of a patch to implement
table-level log_autovacuum_min_duration.

Michael Paquier sent in two revisions of a patch to create
non-erroring memory allocation functions.

Michael Paquier sent in a patch to fix a memory leak in receivelog.c
when receiving stream.

Ali Akbar sent in a patch to clarify documentation that made
generate_series(numeric, numeric) harder to implement.

Oskari Saarenmaa sent in a patch to defines custom macros for each
attribute and enables them individually for compilers that support
them and never defines __attribute__.

Andreas Karlsson and Michael Paquier traded patches to reduce the
needed lock strength of triggers and foreign key DDL.

Marco Nenciarini sent in two more revisions of a patch to implement
incremental backup.

Kyotaro HORIGUCHI sent in three more revisions of a patch to allow
async execution of the PostgreSQL FDW.

Tomas Vondra sent in another revision of a patch to reduce the amount
of memory consumed by array_agg().

Michael Paquier sent in a patch to make mere absence of destination
folders not be a failure mode.

Etsuro Fujita sent in a patch to fix an issue where EvalPlanQual
behaves oddly for FDW queries involving system columns.

Heikki Linnakangas sent in two more revisions of a patch to add
pg_rewind.

Adam Brightwell sent in a patch to add some additional role
attributes.

Amit Langote sent in a patch to fix a typo in brin.c.

Dilip Kumar sent in another revision of a patch to allow vacuumdb to
work in parallel.

Gilles Darold sent in a patch to fix an issue in pg_dump with
unusally-named tables.

Robert Haas sent in another revision of a patch to implement parallel
mode and parallel contexts.

Michael Paquier sent in two revisions of a patch to fix a situation
where the error check always bypassed in tablefunc.c.

Alexander Korotkov sent in two more revisions of a patch to implement
fillfactor for GIN indexes.

Andres Freund sent in a patch to fix various shortcomings of the new
PrivateRefCount infrastructure.

Pavel Stehule sent in a patch to add an array_position() function to
PL/pgsql.

Andres Freund and Michael Paquier traded patches to move binaries from
contrib/ to bin/

Pavel Stehule sent in a patch to complete the deprecation of => for
other than pair-like functionality.

Tom Lane sent in a patch to deal with pg_stat wait timeout.

Tom Lane sent in a patch to have the buildfarm clean up temporary
installs when done.

Michael Paquier sent in another revision of a patch to add
recovery_timeout option to control timeout of restore_command nonzero
status code.

--

-- 
Sent via pgsql-announce mailing list (pgsql-announce <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-announce

Steve Singer | 19 Jan 05:22 2015

Slony 2.2.4 released

The Slony team is pleased to announce Slony 2.2.4 the next minor release 
of the Slony 2.2.x series.

Slony 2.2.4 includes the following changes

  - Bug 352 :: Handle changes from PG HEAD ("9.5")
  - Bug 349 :: Issue with quoting of cluster name - only hit when 
processing DDL
  - Bug 350 :: Make cleanup_interval config parameter work as expected
  - Include alloca.h in slonik(fix for solaris)
  - Bug     :: 345 Fix bug when dropping multiple nodes at once
  - Bug 354 :: Fix race condition in FAILOVER
  - Bug 356 :: Perform TRUNCATE ONLY on replicas (when replicating a 
truncate)

Slony 2.2.4 can be downloaded from from the following URL

http://main.slony.info/downloads/2.2/source/slony1-2.2.4.tar.bz2

--

-- 
Sent via pgsql-announce mailing list (pgsql-announce <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-announce

Daniele Varrazzo | 16 Jan 03:15 2015
Picon

pgmp 1.0.2 released: PostgreSQL-GMP bindings

Hello,

pgmp 1.0.2 has been released: this version fixes build problems with
PostgreSQL 9.3 and 9.4.

pgmp is a PostgreSQL extension module to add support for the arbitrary
precision data types offered by the GMP library into the database.

The extension adds the types 'mpz' (arbitrary size integers) and 'mpq'
(arbitrary precision rationals) to PostgreSQL and exposes to the
database all the functions available in the GMP library for these types,
providing:

- higher performance arithmetic on integers respect to the 'decimal'
  data type, using numbers only limited by the 1GB varlena maximum
  size;

- a rational data type for absolute precision storage and arithmetic;

- the use of specialized functions to deal with prime numbers, random
  numbers, factorization directly into the database.

The GMP data types can be stored into the database, used in mixed
arithmetic with other PostgreSQL numeric types and indexed using the
btree or hash methods.

The extension is compatible with PostgreSQL versions from 8.4 and
packaged as a SQL extension in 9.1. The package includes comprehensive
documentation and regression tests.

- Homepage: http://pgmp.projects.postgresql.org/
- Download: http://pgxn.org/dist/pgmp/

--

-- 
Sent via pgsql-announce mailing list (pgsql-announce <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-announce


Gmane