Yugo Nagata | 5 Feb 10:02 2016
Picon

pgpool-II 3.4.4, 3.3.8, 3.2.13, 3.1.16, and 3.0.20 released

Hi,

Pgpool Global Development Group is pleased to announce the availability
of pgpool-II 3.4.4, 3.3.8, 3.2.13, 3.1.16, and 3.0,20. These are the
latest  stable minor versions of each major versions of pgpool-II.

pgpool-II 3.0.20 is the final release of the 3.0.x. This series has reached
"End of Life", and is no longer maintained and does not receive any updates. 

Pgpool-II is a tool to add usefull features to PostgreSQL, including
connection pooling, load balancing, automatic fail over and more.

You can download them from:
http://pgpool.net/mediawiki/index.php/Downloads

===============================================================================

                        3.4.4 (tataraboshi) 2016/02/05

* Version 3.4.4

    This is a bugfix release against pgpool-II 3.4.3.

    __________________________________________________________________

* Bug fixes

    - doc: Fix misinformation regarding load balancing in docs (Tatsuo Ishii)

      In streaming replication mode, DECLARE, FETCH, CLOSE and SHOW are sent
(Continue reading)

Chapman Flack | 1 Feb 05:53 2016
Picon

PL/Java 1.5.0-BETA1 announced; security note.

PL/Java brings functions, triggers, and types in Java. 1.5.0, now
in beta, supports latest PostgreSQL and Java versions with a range
of improvements and fixes.

Project site:   http://tada.github.io/pljava/
Release notes:  http://tada.github.io/pljava/releasenotes.html

Security note:

1.5.0 brings a policy change to a more secure-by-default posture, where
the ability to create functions in 'LANGUAGE java' is no longer
automatically granted to 'public', but can be selectively granted to
roles that will have that responsibility. The change reduces exposure to
a known issue present in 1.5.0 and earlier versions, that will be closed
in a future release; details are in the release notes.

The new policy will be applied in a new installation; permissions will
not be changed in an upgrade, but any site can move to this policy, even
before updating to 1.5.0, with REVOKE USAGE ON LANGUAGE java FROM
public; followed by explicit GRANT commands for the users/roles expected
to create Java functions. Many sites guided by the principle of least
privilege may have chosen such a policy already.

MS Windows note:

1.5.0 development snapshots have been repeatedly tested on Windows
building with Visual Studio (including the Express and Community
editions), and the build documentation covers this combination.
Beta testers should find it straightforward.

(Continue reading)

David Fetter | 1 Feb 06:11 2016
Gravatar

== PostgreSQL Weekly News - January 31 2016 ==

== PostgreSQL Weekly News - January 31 2016 ==

"5432 ... Meet us!", will take place in Milan, Italy on June 28-29, 2016.
The CfP is open until February 28th.
http://5432meet.us/

== PostgreSQL Product News ==

faker_fdw 0.1.0, a foreign data wrapper for PostgreSQL that generates
fake randomized data, released.
https://github.com/guedes/faker_fdw

PostgreDAC 3.1.0 a Delphi/C++ builder for PostgreSQL, released.
http://microolap.com/products/connectivity/postgresdac/download/

== PostgreSQL Jobs for January ==

http://archives.postgresql.org/pgsql-jobs/2016-01/

== PostgreSQL Local ==

Prague PostgreSQL Developer Day 2016 (P2D2 2016) is a two-day conference
that will be held on February 17-18 2016 in Prague, Czech Republic.
Czech language web site below:
http://www.p2d2.cz/

The annual Indian PGday will be held in Bengaluru, Karnataka, India on
February 26, 2016.
http://pgday.in

(Continue reading)

Barbara Milani | 28 Jan 18:56 2016
Picon

Call for papers for "5432 ... Meet us!" is now open

We are pleased to announce the second edition of "5432 ... Meet us!", a 2 day conference that will take place in Milan, Italy on June 28th and 29th, 2016. The call for papers is now open and you can submit your proposals until February 28th.

"5432 ... Meet us!" is focused on PostgreSQL's integration with other open source technologies as well as development practices for innovation in high performing business contexts.

The event is organised by 2ndQuadrant Italy, but we are looking forward to other PostgreSQL companies willing to join us in this project.

Useful links:

- Website: http://5432meet.us/
- Call for papers (English): http://5432meet.us/pdf-en/A4-cfp-en.pdf (PDF)
- Call for papers (Italian): http://5432meet.us/pdf-it/A4-cfp-it.pdf

For any further enquiries, please contact us at info <at> 5432meet.us.

Thank you and ... ciao!
Barbara
-- Barbara Milani - 2ndQuadrant Italia Mobile: +39 347 066 73 49 Tel.: +39 0574 870600 Skype: bam965 it.linkedin.com/pub/barbara-milani/52/434/729/ PostgreSQL Training, Services and Support barbara.milani <at> 2ndquadrant.it | www.2ndquadrant.it
Dickson S. Guedes | 29 Jan 02:57 2016
Picon

faker_fdw 0.1.0 released

I'm please to announce the release 0.1.0 of faker_fdw, a foreign
data wrapper for PostgreSQL that generates fake randomized
data that could help in your automation test tools, or for populating
a database for tests or even for development data.

See examples and how to install it by visiting the project page on
Github:

- https://github.com/guedes/faker_fdw

Pull requests and suggestions will be much appreciated, please
use the issues interface on the project Github page.

Enjoy!

-- 
Dickson S. Guedes
mail/xmpp: guedes <at> guedesoft.net - skype: guediz
http://github.com/guedes - http://guedesoft.net
http://www.postgresql.org.br

--

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

Pavel Golub | 28 Jan 10:38 2016

PostgresDAC 3.1.0 meets PostgreSQL 9.5!

Hello.

PostgresDAC is a direct access component suite for PostgreSQL, EnterpriseDB
and Heroku Postgres. It allows you to create Delphi/C++Builder
applications with direct access to PostgreSQL/EnterpriseDB/Heroku
Postgres DB without BDE and ODBC.

Support for PostgreSQL 9.5 added.

Full changelog:

[!] v9.5.0 client libraries added
[!] v9.5.0 dump & restore libraries (pg_dump.dll, pg_restore.dll) added
[+] "EPSQLDatabaseError.ErrrorXXX properties contain old values in some scenarios" bug fixed
[+] doEnableRowSecurity option introduced for TPSQLDump.Options property
[+] doIfExists option introduced for TPSQLDump.Options property
[+] roEnableRowSecurity option introduced for TPSQLRestore.Options property
[+] roIfExists option introduced for TPSQLRestore.Options property
[+] TestSSLConnect case added for TPSQLDatabase unit test
[+] tiSERIALIZABLE option added for TPSQLDatabase.TransIsolation property value
[+] TPgSSHDatabase.AddSSHKeyToSystemCache property added
[+] TPgSSHDatabase.ShowPLinkConsole property added
[+] TPSQLDatabase.Assign implemented
[+] TPSQLDump.Snapshot property introduced
[*] More informative message introduced for TPgSSHDatabase connection errors
[*] PSQLMetadata unit excluded as deprecated
[*] TPSQLStoredProc.RefreshParams now throws exception if connection error occurred
[-] "Error code in TPSQLDatabase.StartTransaction ignored" bug fixed

You're welcome to download the latest release right now at:
http://microolap.com/products/connectivity/postgresdac/download/
or login to your private area on our site at
http://microolap.com/my/downloads/

-- 
With best wishes,
 Pavel                          mailto:pavel <at> gf.microolap.com

--

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

Tatsuo Ishii | 29 Jan 11:18 2016

pgpool-II/pgpoolAdmin 3.5 release

Pgpool Global Development Group is pleased to announce the availability of
pgpool-II 3.5.0 and pgpoolAdmin 3.5.0.

You can download the source codes and RPMs from:
http://pgpool.net/mediawiki/index.php/Downloads

pgpool-II is a cluster management tool dedicated for
PostgreSQL. pgpoolAdmin is a web GUI interface for pgpool-II.

V3.5 new features include:

- Improved performance in extended query protocol
- Overcoming the thundering herd problem
- Watchdog feature enhancements to be more robust and adaptable
- PCP command enhancements
- Import PostgreSQL 9.5 parser

Please see the below for details:
http://pgpool.net/mediawiki/index.php?title=pgpool-II_3.5_features&redirect=no

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

--

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

David Fetter | 25 Jan 06:30 2016
Gravatar

== PostgreSQL Weekly News - January 24 2016 ==

== PostgreSQL Weekly News - January 24 2016 ==

The 8th PostgreSQL Session will be held on April 6th, 2016, in Lyon,
France.  The CfP is open until February 29, 2016 at call-for-paper
<AT> postgresql-sessions <DOT> org.

== PostgreSQL Product News ==

pgBadger 7.3, a parallel PostgreSQL log analyzer written in Perl, released:
http://dalibo.github.io/pgbadger/
Development:
https://github.com/dalibo/pgbadger/

PyGreSQL 4.2, a Python driver for PostgreSQL, released.
http://www.pygresql.org/

== PostgreSQL Jobs for January ==

http://archives.postgresql.org/pgsql-jobs/2016-01/

== PostgreSQL Local ==

FOSDEM PGDay is a one day conference that will be held ahead of FOSDEM in
Brussels, Belgium, on Jan 29th, 2016.  Registration is still open.
http://fosdem2016.pgconf.eu/

Prague PostgreSQL Developer Day 2016 (P2D2 2016) is a two-day conference
that will be held on February 17-18 2016 in Prague, Czech Republic.
Czech language web site below:
http://www.p2d2.cz/

The annual Indian PGday will be held in Bengaluru, Karnataka, India on
February 26, 2016.
http://pgday.in

The first pan-Asian PostgreSQL conference will be held March 16-17,
2016 in Singapore.
http://2016.pgday.asia/

Nordic PGDay 2016 is a one day one track conference which will be held in
Helsinki, Finland, on March 17, 2016.  Registration is still open.
http://2016.nordicpgday.org/

PGConf US 2016 will take place April 18-20, 2016 in NYC.  The CfP is
open until January 31st, 2016, 11:59pm EST.
http://www.pgconf.us/2016/

LinuxFest Northwest will take place April 23-24, 2016 at Bellingham
Technical College in Bellingham, Washington, USA.  The CfP is now
open.
http://www.linuxfestnorthwest.org/2016/present

FOSS4G NA, will be held May 2-5, 2016 in Raleigh, North Carolina.
The CfP is open.
https://2016.foss4g-na.org/cfp

PGCon 2016 will be held May 17-21, 2016 in Ottawa.
http://www.pgcon.org/

This year's Swiss PGDay will be held on June 24, 2016 at the
University of Applied Sciences in Rapperswil (Switzerland).
The CfP is open.
http://www.pgday.ch/

== 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 ==

Tom Lane pushed:

- Re-pgindent a few files.  In preparation for landing index AM
  interface changes.
  http://git.postgresql.org/pg/commitdiff/8d290c8ec6c182a4df1d089c21fe84c7912f01fe

- Restructure index access method API to hide most of it at the C
  level.  This patch reduces pg_am to just two columns, a name and a
  handler function.  All the data formerly obtained from pg_am is now
  provided in a C struct returned by the handler function.  This is
  similar to the designs we've adopted for FDWs and tablesample
  methods.  There are multiple advantages.  For one, the index AM's
  support functions are now simple C functions, making them faster to
  call and much less error-prone, since the C compiler can now check
  function signatures.  For another, this will make it far more
  practical to define index access methods in installable extensions.
  A disadvantage is that SQL-level code can no longer see attributes
  of index AMs; in particular, some of the crosschecks in the
  opr_sanity regression test are no longer possible from SQL.  We've
  addressed that by adding a facility for the index AM to perform such
  checks instead.  (Much more could be done in that line, but for now
  we're content if the amvalidate functions more or less replace what
  opr_sanity used to do.) We might also want to expose some sort of
  reporting functionality, but this patch doesn't do that.  Alexander
  Korotkov, reviewed by Petr Jelínek, and rather heavily editorialized
  on by me.
  http://git.postgresql.org/pg/commitdiff/65c5fcd353a859da9e61bfb2b92a99f12937de3b

- Add explicit cast to amcostestimate call.  My compiler doesn't
  complain here, but David Rowley's does ...
  http://git.postgresql.org/pg/commitdiff/49b49506502026a3653bca490c939dc8934afe95

- Fix assorted inconsistencies in GiST opclass support function
  declarations.  The conventions specified by the GiST SGML
  documentation were widely ignored.  For example, the strategy-number
  argument for "consistent" and "distance" functions is specified to
  be a smallint, but most of the built-in support functions declared
  it as an integer, and for that matter the core code passed it using
  Int32GetDatum not Int16GetDatum.  None of that makes any real
  difference at runtime, but it's quite confusing for newcomers to the
  code, and it makes it very hard to write an amvalidate() function
  that checks support function signatures.  So let's try to instill
  some consistency here.  Another similar issue is that the "query"
  argument is not of a single well-defined type, but could have
  different types depending on the strategy (corresponding to search
  operators with different righthand-side argument types).  Some of
  the functions threw up their hands and declared the query argument
  as being of "internal" type, which surely isn't right ("any" would
  have been more appropriate); but the majority position seemed to be
  to declare it as being of the indexed data type, corresponding to a
  search operator with both input types the same.  So I've specified a
  convention that that's what to do always.  Also, the result of the
  "union" support function actually must be of the index's storage
  type, but the documentation suggested declaring it to return
  "internal", and some of the functions followed that.  Standardize on
  telling the truth, instead.  Similarly, standardize on declaring the
  "same" function's inputs as being of the storage type, not
  "internal".  Also, somebody had forgotten to add the "recheck"
  argument to both the documentation of the "distance" support
  function and all of their SQL declarations, even though the C code
  was happily using that argument.  Clean that up too.  Fix up some
  other omissions in the docs too, such as documenting that union's
  second input argument is vestigial.  So far as the errors in core
  function declarations go, we can just fix pg_proc.h and bump
  catversion.  Adjusting the erroneous declarations in contrib modules
  is more debatable: in principle any change in those scripts should
  involve an extension version bump, which is a pain.  However, since
  these changes are purely cosmetic and make no functional difference,
  I think we can get away without doing that.
  http://git.postgresql.org/pg/commitdiff/9ff60273e35cad6e9d3a4adf59d5c2455afe9d9e

- Fix assorted inconsistencies in GIN opclass support function
  declarations.  GIN had some minor issues too, mostly using
  "internal" where something else would be more appropriate.  I went
  with the same approach as in 9ff60273e35cad6e, namely preferring the
  opclass' indexed datatype for arguments that receive an operator RHS
  value, even if that's not necessarily what they really are.  Again,
  this is with an eye to having a uniform rule for ginvalidate() to
  check support function signatures.
  http://git.postgresql.org/pg/commitdiff/dbe2328959e12701fade6b500ad411271923d6e4

- Add defenses against putting expanded objects into Const nodes.
  Putting a reference to an expanded-format value into a Const node
  would be a bad idea for a couple of reasons.  It'd be possible for
  the supposedly immutable Const to change value, if something
  modified the referenced variable ... in fact, if the Const's
  reference were R/W, any function that has the Const as argument
  might itself change it at runtime.  Also, because datumIsEqual() is
  pretty simplistic, the Const might fail to compare equal to other
  Consts that it should compare equal to, notably including copies of
  itself.  This could lead to unexpected planner behavior, such as
  "could not find pathkey item to sort" errors or inferior plans.  I
  have not been able to find any way to get an expanded value into a
  Const within the existing core code; but Paul Ramsey was able to
  trigger the problem by writing a datatype input function that
  returns an expanded value.  The best fix seems to be to establish a
  rule that varlena values being placed into Const nodes should be
  passed through pg_detoast_datum().  That will do nothing (and cost
  little) in normal cases, but it will flatten expanded values and
  thereby avoid the above problems.  Also, it will convert
  short-header or compressed values into canonical format, which will
  avoid possible unexpected lack-of-equality issues for those cases
  too.  And it provides a last-ditch defense against putting a toasted
  value into a Const, which we already knew was dangerous, cf commit
  2b0c86b66563cf2f.  (In the light of this discussion, I'm no longer
  sure that that commit provided 100% protection against such cases,
  but this fix should do it.) The test added in commit
  65c3d05e18e7c530 to catch datatype input functions with unstable
  results would fail for functions that returned expanded values; but
  it seems a bit uncharitable to deem a result unstable just because
  it's expressed in expanded form, so revise the coding so that we
  check for bitwise equality only after applying pg_detoast_datum().
  That's a sufficient condition anyway given the new rule about
  detoasting when forming a Const.  Back-patch to 9.5 where the
  expanded-object facility was added.  It's possible that this should
  go back further; but in the absence of clear evidence that there's
  any live bug in older branches, I'll refrain for now.
  http://git.postgresql.org/pg/commitdiff/b99551832e79c915e4d877cf0a072120bd248748

- Suppress compiler warning.  Given the limited range of i, these
  shifts should not cause any problem, but that apparently doesn't
  stop some compilers from whining about them.  David Rowley
  http://git.postgresql.org/pg/commitdiff/d9b9289c837a98b78b948b597fabd9ab0a96c0db

- Improve index AMs' opclass validation procedures.  The amvalidate
  functions added in commit 65c5fcd353a859da were on the crude side.
  Improve them in a few ways: * Perform signature checking for
  operators and support functions.  * Apply more thorough checks for
  missing operators and functions, where possible.  * Instead of
  reporting problems as ERRORs, report most problems as INFO messages
  and make the amvalidate function return FALSE.  This allows more
  than one problem to be discovered per run.  * Report object names
  rather than OIDs, and work a bit harder on making the messages
  understandable.  Also, remove a few more opr_sanity regression test
  queries that are now superseded by the amvalidate checks.
  http://git.postgresql.org/pg/commitdiff/be44ed27b86ebd165bbedf06a4ac5a8eb943d43c

- Make extract() do something more reasonable with infinite datetimes.
  Historically, extract() just returned zero for any case involving an
  infinite timestamp[tz] input; even cases in which the unit name was
  invalid.  This is not very sensible.  Instead, return infinity or
  -infinity as appropriate when the requested field is one that is
  monotonically increasing (e.g, year, epoch), or NULL when it is not
  (e.g., day, hour).  Also, throw the expected errors for bad unit
  names.  BACKWARDS INCOMPATIBLE CHANGE Vitaly Burovoy, reviewed by
  Vik Fearing
  http://git.postgresql.org/pg/commitdiff/647d87c56ab6da70adb753c08d7cdf7ee905ea8a

- Remove new coupling between NAMEDATALEN and MAX_LEVENSHTEIN_STRLEN.
  Commit e529cd4ffa605c6f introduced an Assert requiring NAMEDATALEN
  to be less than MAX_LEVENSHTEIN_STRLEN, which has been 255 for a
  long time.  Since up to that instant we had always allowed
  NAMEDATALEN to be substantially more than that, this was
  ill-advised.  It's debatable whether we need MAX_LEVENSHTEIN_STRLEN
  at all (versus putting a CHECK_FOR_INTERRUPTS into the loop), or
  whether it has to be so tight; but this patch takes the narrower
  approach of just not applying the MAX_LEVENSHTEIN_STRLEN limit to
  calls from the parser.  Trusting the parser for this seems
  reasonable, first because the strings are limited to NAMEDATALEN
  which is unlikely to be hugely more than 256, and second because the
  maximum distance is tightly constrained by MAX_FUZZY_DISTANCE
  (though we'd forgotten to make use of that limit in one place).
  That means the cost is not really O(mn) but more like O(max(m,n)).
  Relaxing the limit for user-supplied calls is left for future
  research; given the lack of complaints to date, it doesn't seem very
  high priority.  In passing, fix confusion between lengths-in-bytes
  and lengths-in-chars in comments and error messages.  Per gripe from
  Kevin Day; solution suggested by Robert Haas.  Back-patch to 9.5
  where the unwanted restriction was introduced.
  http://git.postgresql.org/pg/commitdiff/a396144ac03b0cf337f80201df7e4663cc5a8131

- Improve levenshtein() docs.  Fix chars-vs-bytes confusion here too.
  Improve poor grammar and markup.
  http://git.postgresql.org/pg/commitdiff/80aa219146c090d46b599ac40d8d63e30532b622

- Improve cross-platform consistency of Inf/NaN handling in trig
  functions.  Ensure that the trig functions return NaN for NaN input
  regardless of what the underlying C library functions might do.
  Also ensure that an error is thrown for Inf (or otherwise
  out-of-range) input, except for atan/atan2 which should accept it.
  All these behaviors should now conform to the POSIX spec;
  previously, all our popular platforms deviated from that in one case
  or another.  The main remaining platform dependency here is whether
  the C library might choose to throw a domain error for sin/cos/tan
  inputs that are large but less than infinity.  (Doing so is not
  unreasonable, since once a single unit-in-the-last-place exceeds PI,
  there can be no significance at all in the result; however there
  doesn't seem to be any suggestion in POSIX that such an error is
  allowed.)  We will report such errors if they are reported via
  "errno", but not if they are reported via "fetestexcept" which is
  the other mechanism sanctioned by POSIX.  Some preliminary
  experiments with fetestexcept indicated that it might also report
  errors we could do without, such as complaining about underflow at
  an unreasonably large threshold.  So let's skip that complexity for
  now.  Dean Rasheed, reviewed by Michael Paquier
  http://git.postgresql.org/pg/commitdiff/fd5200c3dca0bc725f5848eef7ffff538f4479ed

- Add trigonometric functions that work in degrees.  The
  implementations go to some lengths to deliver exact results for
  values where an exact result can be expected, such as sind(30) = 0.5
  exactly.  Dean Rasheed, reviewed by Michael Paquier
  http://git.postgresql.org/pg/commitdiff/e1bd684a34c11139a1bf4e5200c3bbe59a0fbfad

- Adjust degree-based trig functions for more portability.  The
  buildfarm isn't very happy with the results of commit
  e1bd684a34c11139.  To try to get the expected exact results
  everywhere: * Replace M_PI / 180 subexpressions with a precomputed
  constant, so that the compiler can't decide to rearrange that
  division with an adjacent operation.  Hopefully this will fix
  failures to get exactly 0.5 from sind(30) and cosd(60).  * Add
  scaling to ensure that tand(45) and cotd(45) give exactly 1; there
  was nothing particularly guaranteeing that before.  * Replace minus
  zero by zero when tand() or cotd() would output that; many machines
  did so for tand(180) and cotd(270), but not all.  We could
  alternatively deem both results valid, but that doesn't seem likely
  to be what users will want.
  http://git.postgresql.org/pg/commitdiff/73193d82d7c8d849774bf6952dfb4287e213c572

- Further adjust degree-based trig functions for more portability.
  The last round didn't do it.  Per Noah Misch, the problem on at
  least some machines is that the compiler pre-evaluates trig
  functions having constant arguments using code slightly different
  from what will be used at runtime.  Therefore, we must prevent the
  compiler from seeing constant arguments to any of the libm trig
  functions used in this code.  The method used here might still fail
  if init_degree_constants() gets inlined into the call sites.  That
  probably won't happen given the large number of call sites; but if
  it does, we could probably fix it by making init_degree_constants()
  non-static.  I'll avoid that till proven necessary, though.
  http://git.postgresql.org/pg/commitdiff/65abaab547a5758b0d6d92df4af1663bb47d545f

- Still further adjust degree-based trig functions for more
  portability.  Indeed, the non-static declaration foreseen in my
  previous commit message is necessary.  Per Noah Misch.
  http://git.postgresql.org/pg/commitdiff/360f67d31a5656991122b89c9ca22a860f41512c

- Yet further adjust degree-based trig functions for more portability.
  Buildfarm member cockatiel is still saying that cosd(60) isn't 0.5.
  What seems likely is that the subexpression (1.0 - cos(x)) isn't
  being rounded to double width before more arithmetic is done on it,
  so force that by storing it into a variable.
  http://git.postgresql.org/pg/commitdiff/00347575e2754b1aaacd357776560803564d3f35

Tatsuo Ishii pushed:

- Fix typo.  Reported by KOIZUMI Satoru.
  http://git.postgresql.org/pg/commitdiff/85f22281a1190165851f15b35f8283c8b7592b3c

Andrew Dunstan pushed:

- Remove Cygwin-specific code from pg_ctl This code has been there for
  a long time, but it's never really been needed. Cygwin has its own
  utility for registering, unregistering, stopping and starting
  Windows services, and that's what's used in the Cygwin postgres
  packages. So now pg_ctl for Cygwin looks like it is for any Unix
  platform.  Michael Paquier and me
  http://git.postgresql.org/pg/commitdiff/53c949c1be2f43cd47cb433923e76ea00e9222bc

Álvaro Herrera pushed:

- Add two HyperLogLog functions.  New functions initHyperLogLogError()
  and freeHyperLogLog() simplify using this module from elsewhere.
  Author: Tomáš Vondra.  Review: Peter Geoghegan
  http://git.postgresql.org/pg/commitdiff/948c97958bf37adb2a9c2d6d92c255abfc7499ba

- PostgresNode: Add names to nodes.  This makes the log files easier
  to follow when investigating a test failure.  Author: Michael
  Paquier.  Review: Noah Misch
  http://git.postgresql.org/pg/commitdiff/c8642d909fdd57c36dd71e0b0bb4071523324794

- pg_dump: Fix quoting of domain constraint names.  The original code
  was adding double quotes to an already-quoted identifier, leading to
  nonsensical results.  Remove the quoting call.  I introduced the
  broken code in 7eca575d1c of 9.5 era, so backpatch to 9.5.  Report
  and patch by Elvis Pranskevichus Reviewed by Michael Paquier
  http://git.postgresql.org/pg/commitdiff/df43fcf4575cf77d85f4c4dcc096661905a6eb33

Bruce Momjian pushed:

- Properly install dynloader.h on MSVC builds.  This will enable
  PL/Java to be cleanly compiled, as dynloader.h is a requirement.
  Report by Chapman Flack Patch by Michael Paquier Backpatch through
  9.1
  http://git.postgresql.org/pg/commitdiff/216d5684325dd2f6959f4859648e7aa908ae0757

Robert Haas pushed:

- Support multi-stage aggregation.  Aggregate nodes now have two new
  modes: a "partial" mode where they output the unfinalized transition
  state, and a "finalize" mode where they accept unfinalized
  transition states rather than individual values as input.  These new
  modes are not used anywhere yet, but they will be necessary for
  parallel aggregation.  The infrastructure also figures to be useful
  for cases where we want to aggregate local data and remote data via
  the FDW interface, and want to bring back partial aggregates from
  the remote side that can then be combined with locally generated
  partial aggregates to produce the final value.  It may also be
  useful even when neither FDWs nor parallelism are in play, as
  explained in the comments in nodeAgg.c.  David Rowley and Simon
  Riggs, reviewed by KaiGai Kohei, Heikki Linnakangas, Haribabu Kommi,
  and me.
  http://git.postgresql.org/pg/commitdiff/a7de3dc5c346e07e0439275982569996e645b3c2

- Support parallel joins, and make related improvements.  The core
  innovation of this patch is the introduction of the concept of a
  partial path; that is, a path which if executed in parallel will
  generate a subset of the output rows in each process.  Gathering a
  partial path produces an ordinary (complete) path.  This allows us
  to generate paths for parallel joins by joining a partial path for
  one side (which at the baserel level is currently always a Partial
  Seq Scan) to an ordinary path on the other side.  This is subject to
  various restrictions at present, especially that this strategy seems
  unlikely to be sensible for merge joins, so only nested loops and
  hash joins paths are generated.  This also allows an Append node to
  be pushed below a Gather node in the case of a partitioned table.
  Testing revealed that early versions of this patch made poor
  decisions in some cases, which turned out to be caused by the fact
  that the original cost model for Parallel Seq Scan wasn't very good.
  So this patch tries to make some modest improvements in that area.
  There is much more to be done in the area of generating good
  parallel plans in all cases, but this seems like a useful step
  forward.  Patch by me, reviewed by Dilip Kumar and Amit Kapila.
  http://git.postgresql.org/pg/commitdiff/45be99f8cd5d606086e0a458c9c72910ba8a613d

Simon Riggs pushed:

- Refactor to create generic WAL page read callback.  Previously we
  didn’t have a generic WAL page read callback function, surprisingly.
  Logical decoding has logical_read_local_xlog_page(), which was
  actually generic, so move that to xlogfunc.c and rename to
  read_local_xlog_page().  Maintain logical_read_local_xlog_page() so
  existing callers still work.  As requested by Michael Paquier,
  Alvaro Herrera and Andres Freund
  http://git.postgresql.org/pg/commitdiff/422a55a68784fd00f4514834f3649140a9166fa5

- Speedup 2PC by skipping two phase state files in normal path.  2PC
  state info is written only to WAL at PREPARE, then read back from
  WAL at COMMIT PREPARED/ABORT PREPARED. Prepared transactions that
  live past one bufmgr checkpoint cycle will be written to disk in the
  same form as previously. Crash recovery path is not altered.
  Measured performance gains of 50-100% for short 2PC transactions by
  completely avoiding writing files and fsyncing. Other optimizations
  still available, further patches in related areas expected.  Stas
  Kelvich and heavily edited by Simon Riggs Based upon earlier ideas
  and patches by Michael Paquier and Heikki Linnakangas, a concrete
  example of how Postgres-XC has fed back ideas into PostgreSQL.
  Reviewed by Michael Paquier, Jeff Janes and Andres Freund
  Performance testing by Jesper Pedersen
  http://git.postgresql.org/pg/commitdiff/978b2f65aa1262eb4ecbf8b3785cb1b9cf4db78e

- Refactor headers to split out standby defs Jeff Janes
  http://git.postgresql.org/pg/commitdiff/c80b31d557cb4b2d2a65cb0a7e71fd961834fdb2

- Correct comment in GetConflictingVirtualXIDs() We use Share lock
  because it is safe to do so.
  http://git.postgresql.org/pg/commitdiff/1129c2b0ad2732f301f696ae2cf98fb063a4c1f8

Peter Eisentraut pushed:

- psql: Add tab completion for COPY with query.  From: Andreas
  Karlsson <andreas <at> proxel.se>
  http://git.postgresql.org/pg/commitdiff/d0f2f53cd6f2f1fe6e53b8e3bfcce43c16ea851b

- psql: Improve completion of FDW DDL commands.  Add ALTER FOREIGN
  DATA WRAPPER -> RENAME TO, ALTER SERVER -> RENAME TO, ALTER SERVER
  ... VERSION ... -> OPTIONS, CREATE FOREIGN DATA WRAPPER -> OPTIONS ,
  CREATE SERVER -> OPTIONS, CREATE|ALTER USER MAPPING -> OPTIONS From:
  Andreas Karlsson <andreas <at> proxel.se>
  http://git.postgresql.org/pg/commitdiff/6ae4c8de00c382b10e851e1eaf7f5e19e143b251

Fujii Masao pushed:

- Remove unused argument from ginInsertCleanup() It's an oversight in
  commit dc943ad.
  http://git.postgresql.org/pg/commitdiff/38710a374ea9a29159ff12af7dbecd2959476447

== Rejected Patches (for now) ==

No one was disappointed this week :-)

== Pending Patches ==

Alexander Shulgin sent in a patch to fix some IDENTIFICATION
divisions.

Dmitry Dolgov sent in another revision of a patch to add array-style
subscripting to JSONB.

Tomas Vondra sent in another revision of a patch to add multivariate
statistics.

Bruce Momjian and Joe Conway traded patches to expose pg_controldata
and pg_config as functions.

Artur Zakirov sent in two more revisions of a patch to implement fuzzy
substring searching with the pg_trgm extension.

Ashutosh Bapat sent in two more revisions of a patch to add
postgres_fdw join pushdown.

Vitaly Burovoy and Pavel Stěhule traded patches to add a custom
function for converting human readable sizes to bytes.

Dilip Kumar sent in another revision of a patch to move PinBuffer and
UnpinBuffer to atomics.

Thomas Munro sent in another revision of a patch to add causal reads.

SAWADA Masahiko sent in another revision of a patch to allow multiple
synchronous standby servers.

Alexander Shulgin sent in another revision of a patch to add an
extension called pg_logical_slot_stream_relation.

Tatsuo Ishii sent in a patch to fix a too-enthusiastic quoting of
identifiers with the high bit set.

Anastasia Lubennikova sent in two more revisions of a patch to
implement covering unique indexes.

Robert Haas and Etsuro Fujita traded patches to optimize write
operations on the PostgreSQL FDW.

Haribabu Kommi sent in two more revisions of a patch to do aggregation
in parallel.

David Rowley sent in another revision of a patch to serialize internal
aggregate states.

Haribabu Kommi sent in two more revisions of a patch to add combine
functions for staged aggregates.

Kyotaro HORIGUCHI sent in another revision of a patch to allow
async-capable nodes to register callbacks to run the node before
ExecProcNode() and provide an example using same.

Etsuro Fujita sent in another revision of a patch to optimize
create_foreignscan_plan/ExecInitForeignScan.

Daniel Verité sent in another revision of a patch to add a
\crosstabview to psql.

Tomas Vondra and David Rowley traded patches to optimize outer joins
where the outer side is unique.

Petr Jelínek sent in another revision of a patch to enable generic WAL
logical messages.

David Rowley sent in a patch to fix an issue where combining
aggretates didn't work with pg_dump.

Victor Wagner sent in another revision of a patch to implement
failover on the libpq connect level.

Aleksander Alekseev sent in another revision of a patch to optimize
dynahashes.

Tomas Vondra sent in another revision of a patch to ensure that more
predictable column statistics are being gathered and used.

Fabien COELHO sent in another revision of a patch to add better
logging, etc. to pgbench.

David Rowley sent in another revision of a patch to remove
functionally dependent GROUP BY columns.

Alexander Korotkov sent in another revision of a patch to add partial
sorts.

Pavel Stěhule sent in another revision of a patch to add a
parse_ident() function.

Artur Zakirov sent in another revision of a patch to copy regexp_t.

--

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

D'Arcy J.M. Cain | 21 Jan 23:33 2016

Release of PyGreSQL version 4.2

The PyGreSQL team is please to announce release 4.2 of PyGreSQL.  It is
available at: http://pygresql.org/files/PyGreSQL-4.2.tgz.

If you are running NetBSD, look in the packages directory under
databases for py-postgresql. There should also be a package in the
FreeBSD ports collection.

Please refer to the changelog for things that have changed in this
version.  The changelog and other information can be found at the web
site http://www.pygresql.org/.

This version has been built and unit tested on:
 - NetBSD
 - FreeBSD
 - openSUSE
 - Ubuntu
 - Windows 7 with both MinGW and Visual Studio
 - PostgreSQL 8.4 and 9.3 64bit
 - Python 2.4, 2.5, 2.6 and 2.7 32 and 64bit

This is the last major release before 5.0 which will include support
for Python 3.x.  Only bug fixes will be applied to this branch.  A beta
of 5.0 is available at http://pygresql.org/files/PyGreSQL-beta.tar.gz.

-- 
D'Arcy J.M. Cain
PyGreSQL Development Group
http://www.PyGreSQL.org IM:darcy <at> Vex.Net

--

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

Virginie Jourdan | 20 Jan 11:24 2016

Call for Papers, PostgreSQL and PostGIS, Session #8, April, 6th

Paris, January 20th 2016

After seven successful sessions dedicated to the new features of PostgreSQL 9.0 (February 2011), to PostGIS (June 2011 & September 2014), to replication systems (February 2012), to migration from Oracle to PostgreSQL (October 2012), to PostgreSQL performance (March 2013) and to our 10th anniversary, in September 2015, we'd like to announce that the 8th PostgreSQL Session will be held on April 6th, 2016, in Lyon, France. 

This year, another place, but always the same format! Indeed, Dalibo and Oslandia organize together one day of lectures dedicated to PostgreSQL and PostGIS.

We're launching a call for papers for this event. You may now submit your talks, in English or in French. Each talk should last 30 minutes (questions included). We are interested in any talks on the following subjects:

PostgreSQL :

  • What's New in PostgreSQL 
  • Use cases 
  • Migration to PostgreSQL
  • Performance Tuning 
  • Backup and Restore
  • High-Availability
  • Data Warehouse / Big Data

PostGIS :

  • Advanced spatial analysis with PostgreSQL/PostGIS
  • PointCloud Data and/or 3D with PostgreSQL/PostGIS
  • Performances improvements with PostgreSQL/PostGIS


Talks can be either: a case study, a Proof of Concept, a tutorial, a benchmark, a presentation of a new feature, etc. Of course, we're open to propositions on any other migration related topics (monitoring, hardware, replication, etc.) !

The submission deadline is February 29, 2016. 

You can now send your proposals to call-for-paper <at> postgresql-sessions.org

Please give us a little information about yourself and your talk, such as:

  • First Name and Last Name
  • Twitter Account (if any)
  • Company
  • Short Biography (contributions to the PostgreSQL community)
  • Talk title
  • Talk abstract
  • Any specific needs

Slides should have a free licence (Creative Commons BY-ND 3.0 or compatible), and sent to Dalibo.
This day will be filmed, and all the lectures will be recorded and published after the Session. By sending a proposal, you agree to be recorded and waive any compensation for it.
The selected speakers not living in France will be reimbursed for travel and one night accomodation.

See you in Lyon in April !


About the PostgreSQL Sessions :

The PostgreSQL sessions are designed to be a time to discover and meet the community. Each session is a single day consisting of lectures, organized around a specific theme and a guest. The proposed talks aimed at all levels and all profiles: Developer, Administrator, Project Managers, IT Managers, ...
Entry is free and open to all, within the limits of available seats.

About Dalibo :

Since 2005, Dalibo is the leading French PostgreSQL company and provides its experience and expertise to its clients in Europe. The company
delivers a full range of PostgreSQL services: Training, Development, Performance Tuning, High Availibilty setup, Oracle to
PostgreSQL migration, Troubleshooting, and PostgreSQL support.

About Oslandia :

Oslandia is a company with a focus on Open Source GIS architecture.
We are characterized by our expertise, agility and dynamism.
Our business model is based on services around Open Source GIS software which we are expert on.
More than just offering expertise, we are also software editor for some OpenSource GIS components we develop, renown and used worldwide (PostGIS, MapServer Suite, QGIS).
This implication requires us to be in the heart of communities of developers and standardisation (worldwide codesprints, participation in future software version orientation, new feature development on our own R&D budgets...).
Gilles Darold | 18 Jan 11:45 2016

pgBadger 7.3

Paris, France - January 18th, 2016

pgBadger 7.3 was released today to fix a major bug. Everyone using
version 7.2 and the incremental mode of pgBadger must upgrade.

pgBadger is a PostgreSQL performance analyzer, built for speed with
fully detailed reports based on your PostgreSQL log files.

This is a maintenance release to fix a major bug that was breaking
the incremental mode in pgBadger. It also adds some more reports and
features.

  * Add --timezone=+/-HH to control the timezone used in charts. The
    javascript library runs at client side so the timezone used is
    the browser timezone so the displayed time in the charts can be
    different from the time in the log file.
  * Add /tmp/pgbadger.pid file to prevent cron jobs overlaping on
    same log files.
  * Add command line option --pid-dir to be able to run two pgbadger
    at the same time by setting an alternate path to the pid file.
  * Report information about "LOG:  skipping analyze of ..." into
    events reports.
  * Report message "LOG: sending cancel to blocking autovacuum" into
   events reports. Useful to look for queries generating autovacuum
    kill on account of a lock issue.

For the complete list of changes, please checkout the release note on
https://github.com/dalibo/pgbadger/blob/master/ChangeLog

===== Links & Credits =====

DALIBO would like to thank the developers who submitted patches and the
users who reported bugs and feature requests, especially CZAirwolf for
for the help to fix the incremental bug issue.

pgBadger is an open project. 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 directly on our mailing list.

Links :

  * Download : https://github.com/dalibo/pgbadger/releases/
  * Mailing List :
https://groups.google.com/forum/?hl=fr#!forum/pgbadger
(pgbadger <at> googlegroups.com)

--------------

**About pgBadger** :

pgBagder is a new generation log analyzer for PostgreSQL, created by
Gilles Darold (also author of ora2pg, the powerful migration tool).
pgBadger is a fast and easy tool to analyze your SQL traffic and create
HTML5 reports with dynamics graphs. pgBadger is the perfect tool to
understand the behavior of your PostgreSQL servers and identify which
SQL queries need to be optimized.

Docs, Download & Demo at http://dalibo.github.io/pgbadger/

--------------

**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

-- 
Gilles Darold
Consultant PostgreSQL
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


Gmane