== PostgreSQL Weekly News - January 14 2018 ==

== PostgreSQL Weekly News - January 14 2018 ==

== PostgreSQL Product News ==

Pgpool-II 3.7.1, 3.6.8, 3.5.12, 3.4.15 and 3.3.19 released.
http://www.pgpool.net/docs/latest/en/html/release.html

pglogical 2.1.1, a logical-WAL-based replication system for PostgreSQL, released.
https://www.2ndquadrant.com/en/resources/pglogical/

== PostgreSQL Jobs for January ==

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

== PostgreSQL Local ==

FOSDEM PGDay 2018, a one day conference held before the main FOSDEM event will
be held in Brussels, Belgium, on Feb 2nd, 2018.
https://2018.fosdempgday.org/

Prague PostgreSQL Developer Day 2018 (P2D2 2018) is a two-day
conference that will be held on February 14-15 2018 in Prague, Czech Republic.
http://www.p2d2.cz/

PGConf India 2018 will be on February 22-23, 2018 in Bengaluru, Karnataka.
http://pgconf.in/

PostgreSQL(at)SCaLE is a two day, two track event which takes place on
March 8-9, 2018, at Pasadena Convention Center, as part of SCaLE 16X.
http://www.socallinuxexpo.org/scale/16x/cfp

Nordic PGDay 2018 will be held in Oslo, Norway, at the Radisson Blu Hotel
Nydalen, on March 13, 2018. The CfP is open through December 31, 2017 at
https://2018.nordicpgday.org/cfp/

pgDay Paris 2018 will be held in Paris, France at the Espace Saint-Martin, on
March 15 2018. The CfP is open until December 31, 2017.
http://2018.pgday.paris/callforpapers/

PGConf APAC 2018 will be held in Singapore March 22-23, 2018.
http://2018.pgconfapac.org/

The German-speaking PostgreSQL Conference 2018 will take place on April 13th,
2018 in Berlin.
http://2018.pgconf.de/

PGConfNepal 2018 will be held May 4-5, 2018 at Kathmandu University, Dhulikhel,
Nepal. The CfP is open until 2018-02-01 at
https://postgresconf.org/conferences/Nepal2018/program/proposals
https://postgresconf.org/conferences/Nepal2018

PGCon 2018 will take place in Ottawa on May 29 - June 1, 2018. The CFP is open
until January 19, 2018 at https://www.pgcon.org/2018/papers.php
https://www.pgcon.org/2018/

PGConf.Brazil 2018 will take place in São Paulo, Brazil on August 3-4 2018. The
CfP will open soon.
http://pgconf.com.br

== 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 EST5EDT. Please send English
language ones to david(at)fetter(dot)org, German language to pwn(at)pgug(dot)de, Italian
language to pwn(at)itpug(dot)org(dot)

== Applied Patches ==

Tom Lane pushed:

- Back off chattiness in RemovePgTempFiles(). In commit 561885db0, as part of
normalizing RemovePgTempFiles's error handling, I removed its behavior of
silently ignoring ENOENT failures during directory opens. Thomas Munro points
out that this is a bad idea at the top level, because we don't create
pgsql_tmp directories until needed. Thus this coding could produce LOG
messages in perfectly normal situations, which isn't what I intended. Restore
the suppression of ENOENT logging, but only at top level --- it would still be
unexpected for a nested temp directory to disappear between seeing it in the
parent directory and opening it. Discussion:
https://postgr.es/m/CAEepm=2y06SehAkTnd5sU_eVqdv5P-=Srt1y5vYNQk6yVDVaPw@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/eeb3c2df429c943b2f8d028d110b55ac0a53dc75

- Cosmetic improvements in condition_variable.[hc]. Clarify a bunch of
comments. Discussion:
https://postgr.es/m/CAEepm=0NWKehYw7NDoUSf8juuKOPRnCyY3vuaSvhrEWsOTAa3w@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/e35dba475a440f73dccf9ed1fd61e3abc6ee61db

- Improve error detection capability in proclists. Previously, although the
initial state of a proclist_node is expected to be next == prev == 0,
proclist_delete_offset would reset nodes to next == prev == INVALID_PGPROCNO
when removing them from a list. This is the same state that a node in a
singleton list has, so that it's impossible to distinguish not-in-a-list from
in-a-list. Change proclist_delete_offset to reset removed nodes to next ==
prev == 0, making it possible to distinguish those cases, and then add Asserts
to the list add and delete functions that the supplied node isn't or is in a
list at entry. Also tighten assertions about the node being in the particular
list (not some other one) where it is possible to check that in O(1) time. In
ConditionVariablePrepareToSleep, since we don't expect the process's
cvWaitLink to already be in a list, remove the more-or-less-useless
proclist_contains check; we'd rather have proclist_push_tail's new assertion
fire if that happens. Improve various comments related to proclists, too.
Patch by me, reviewed by Thomas Munro. This isn't back-patchable, since there
could theoretically be inlined copies of proclist_delete_offset in third-party
modules. But it's only improving debuggability anyway. Discussion:
https://postgr.es/m/CAEepm=0NWKehYw7NDoUSf8juuKOPRnCyY3vuaSvhrEWsOTAa3w@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/ea8e1bbc538444d373cf712a0f5188c906b71a9d

- Allow ConditionVariable[PrepareTo]Sleep to auto-switch between CVs. The
original coding here insisted that callers manually cancel any prepared sleep
for one condition variable before starting a sleep on another one. While
that's not a huge burden today, it seems like a gotcha that will bite us in
future if the use of condition variables increases; anything we can do to make
the use of this API simpler and more robust is attractive. Hence, allow these
functions to automatically switch their attention to a different CV when
required. This is safe for the same reason it was OK for commit aced5a92b to
let a broadcast operation cancel any prepared CV sleep: whenever we return to
the other test-and-sleep loop, we will automatically re-prepare that CV,
paying at most an extra test of that loop's exit condition. Back-patch to v10
where condition variables were introduced. Ordinarily we would probably not
back-patch a change like this, but since it does not invalidate any coding
pattern that was legal before, it seems safe enough. Furthermore, there's an
open bug in replorigin_drop() for which the simplest fix requires this. Even
if we chose to fix that in some more complicated way, the hazard would remain
that we might back-patch some other bug fix that requires this behavior.
Patch by me, reviewed by Thomas Munro. Discussion:
https://postgr.es/m/2437.1515368316@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/13db3b936359eebf02a768db3a1959af880b6cc6

- Fix race condition during replication origin drop. replorigin_drop()
misunderstood the API for condition variables: it had
ConditionVariablePrepareToSleep and ConditionVariableCancelSleep inside its
test-and-sleep loop, rather than outside the loop as intended. The net effect
is a narrow race-condition window wherein, if the process using a replication
slot releases it immediately after replorigin_drop() releases the
ReplicationOriginLock, replorigin_drop() would get into the condition
variable's wait list too late and then wait indefinitely for a signal that
won't come. Because there's a different CV for each replication slot, we
can't just move the ConditionVariablePrepareToSleep call to above the
test-and-sleep loop. What we can do, in the wake of commit 13db3b936, is drop
the ConditionVariablePrepareToSleep call entirely. This fix depends on that
commit because (at least in principle) the slot matching the target
replication origin might move around, so that once in a blue moon successive
loop iterations might involve different CVs. We can now cope with such a
scenario, at the cost of an extra trip through the retry loop. (There are
ways we could fix this bug without depending on that commit, but they're all a
lot more complicated than this way.) While at it, upgrade the rather skimpy
comments in this function. Back-patch to v10 where this code came in.
Discussion: https://postgr.es/m/19947.1515455433@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/8a906204aec44de6d8a1514082870f25085d9431

- While waiting for a condition variable, detect postmaster death. The general
assumption for postmaster child processes is that they should just exit(1),
reasonably promptly, if the postmaster disappears. condition_variable.c
neglected this consideration and could be left waiting forever, if the
counterpart process it is waiting for has done the right thing and exited. We
had some discussion of adjusting the WaitEventSet API to make it harder to
make this type of mistake in future; but for the moment, and for v10, let's
make this narrow fix. Discussion:
https://postgr.es/m/20412.1515456143@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/80259d4dbf47d13ef4c105e06c4ea084639d9466

- Rewrite list_qsort() to avoid trashing its input list. The initial
implementation of list_qsort(), from commit ab7271677, re-used the ListCells
of the input list while not touching the List header. This meant that anybody
who still had a pointer to the original header would now be in possession of a
corrupted list, a problem that seems sure to bite us eventually. One possible
solution is to re-use the original List header as well, giving the function
the semantics of update-in-place. However, that doesn't seem like a very good
idea either given the way that the function is used in the planner:
create_path functions aren't normally supposed to modify their input lists.
It doesn't look like there would be a problem today, but it's not hard to
foresee a time when modifying a list of Paths in-place could have side-effects
on some other append path. On the whole, and in view of the likelihood that
this function might be used in other contexts in the future, it seems best to
get rid of the micro-optimization of re-using the input list cells. Just
build a new list. Discussion:
https://postgr.es/m/16912.1515449066@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/3cb1b2a8804da8365fe17f687d96b720df4a583d

- Improve the heuristic for ordering child paths of a parallel append. Commit
ab7271677 introduced code that attempts to order the child scans of a Parallel
Append node in a way that will minimize execution time, based on total cost
and startup cost. However, it failed to think hard about what to do when
estimated costs are exactly equal; a case that's particularly likely to occur
when comparing on startup cost. In such a case the ordering of the child
paths would be left to the whims of qsort, an algorithm that isn't even
stable. We can improve matters by applying the rule used elsewhere in the
planner: if total costs are equal, sort on startup cost, and vice versa. When
both cost estimates are exactly equal, rather than letting qsort do something
unpredictable, sort based on the child paths' relids, which should typically
result in sorting in inheritance order. (The latter provision requires
inventing a qsort-style comparator for bitmapsets, but maybe we'll have use
for that for other reasons in future.) This results in a few plan changes in
the select_parallel test, but those all look more reasonable than before, when
the actual underlying cost numbers are taken into account. Discussion:
https://postgr.es/m/4944.1515446989@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/624e440a474420fa0d6cf26c19bfb256547ab71d

- Remove dubious micro-optimization in ckpt_buforder_comparator(). It seems
incorrect to assume that the list of CkptSortItems can never contain duplicate
page numbers: concurrent activity could result in some page getting dropped
from a low-numbered buffer and later loaded into a high-numbered buffer while
BufferSync is scanning the buffer pool. If that happened, the comparator
would give self-inconsistent results, potentially confusing qsort(). Saving
one comparison step is not worth possibly getting the sort wrong. So far as I
can tell, nothing would actually go wrong given our current implementation of
qsort(). It might get a bit slower than expected if there were a large number
of duplicates of one value, but that's surely a probability-epsilon case.
Still, the comment is wrong, and if we ever switched to another sort
implementation it might be less forgiving. In passing, avoid casting away
const-ness of the argument pointers; I've not seen any compiler complaints
from that, but it seems likely that some compilers would not like it.
Back-patch to 9.6 where this code came in, just in case I've underestimated
the possible consequences. Discussion:
https://postgr.es/m/18437.1515607610@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/3afd75eaac8aaccf5aeebc52548c396b84d85516

- Fix sample INSTR() functions in the plpgsql documentation. These functions
are stated to be Oracle-compatible, but they weren't. Yugo Nagata noticed
that while our code returns zero for a zero or negative fourth parameter
(occur_index), Oracle throws an error. Further testing by me showed that
there was also a discrepancy in the interpretation of a negative third
parameter (beg_index): Oracle thinks that a negative beg_index indicates the
last place where the target substring can *begin*, whereas our code thinks it
is the last place where the target can *end*. Adjust the sample code to
behave like Oracle in both these respects. Also change it to be a CDATA[]
section, simplifying copying-and-pasting out of the documentation source file.
And fix minor problems in the introductory comment, which wasn't very complete
or accurate. Back-patch to all supported branches. Although this patch only
touches documentation, we should probably call it out as a bug fix in the next
minor release notes, since users who have adopted the functions will likely
want to update their versions. Yugo Nagata and Tom Lane Discussion:
https://postgr.es/m/20171229191705.c0b43a8c.nagata@sraoss.co.jp
https://git.postgresql.org/pg/commitdiff/3c1e9fd23269849e32c73683a8457fb3095309e3

- Cosmetic fix in postgres_fdw.c. Make the forward declaration of
estimate_path_cost_size match its actual definition. Tatsuro Yamada
Discussion:
https://postgr.es/m/96f2f554-1eeb-fe6f-e0db-650771886781@lab.ntt.co.jp
https://git.postgresql.org/pg/commitdiff/9ff4f758ee430dbce0be13ab5da315be52cb6f55

- Add QueryEnvironment to ExplainOneQuery_hook's parameter list. This should
have been done in commit 18ce3a4ab, which added that parameter to
ExplainOneQuery, but it was overlooked. This makes it impossible for a user
of the hook to pass the queryEnv down to ExplainOnePlan. It's too late to
change this API in v10, I suppose, but fortunately passing NULL to
ExplainOnePlan will work in nearly all interesting cases in v10. That might
not be true forever, so we'd better fix it. Tatsuro Yamada, reviewed by
Thomas Munro Discussion:
https://postgr.es/m/890e8dd9-c1c7-a422-6892-874f5eaee048@lab.ntt.co.jp
https://git.postgresql.org/pg/commitdiff/4d41b2e0926548e338d20875729a55d41289f867

- Fix incorrect handling of subquery pullup in the presence of grouping sets.
If we flatten a subquery whose target list contains constants or expressions,
when those output columns are used in GROUPING SET columns, the planner was
capable of doing the wrong thing by merging a pulled-up expression into the
surrounding expression during const-simplification. Then the late processing
that attempts to match subexpressions to grouping sets would fail to match
those subexpressions to grouping sets, with the effect that they'd not go to
null when expected. To fix, wrap such subquery outputs in PlaceHolderVars,
ensuring that they preserve their separate identity throughout the planner's
expression processing. This is a bit of a band-aid, because the wrapper
defeats const-simplification even in places where it would be safe to allow.
But a nicer fix would likely be too invasive to back-patch, and the
consequences of the missed optimizations probably aren't large in most cases.
Back-patch to 9.5 where grouping sets were introduced. Heikki Linnakangas,
with small mods and better test cases by me; additional review by Andrew
Gierth Discussion:
https://postgr.es/m/7dbdcf5c-b5a6-ef89-4958-da212fe10176@iki.fi
https://git.postgresql.org/pg/commitdiff/90947674fc984f5639e3b1bf013435a023aa713b

- Avoid unnecessary failure in SELECT concurrent with ALTER NO INHERIT. If a
query against an inheritance tree runs concurrently with an ALTER TABLE that's
disinheriting one of the tree members, it's possible to get a "could not find
inherited attribute" error because after obtaining lock on the removed member,
make_inh_translation_list sees that its columns have attinhcount=0 and decides
they aren't the columns it's looking for. An ideal fix, perhaps, would avoid
including such a just-removed member table in the query at all; but there
seems no way to accomplish that without adding expensive catalog rechecks or
creating a likelihood of deadlocks. Instead, let's just drop the check on
attinhcount. In this way, a query that's included a just-disinherited child
will still succeed, which is not a completely unreasonable behavior. This
problem has existed for a long time, so back-patch to all supported branches.
Also add an isolation test verifying related behaviors. Patch by me; the new
isolation test is based on Kyotaro Horiguchi's work. Discussion:
https://postgr.es/m/20170626.174612.23936762.horiguchi.kyotaro@lab.ntt.co.jp
https://git.postgresql.org/pg/commitdiff/680d540502609b422d378a1b8e0c10cac3c60084

- Fix postgres_fdw to cope with duplicate GROUP BY entries. Commit 7012b132d,
which added the ability to push down aggregates and grouping to the remote
server, wasn't careful to ensure that the remote server would have the same
idea we do about which columns are the grouping columns, in cases where there
are textually identical GROUP BY expressions. Such cases typically led to
"targetlist item has multiple sortgroupref labels" errors. To fix this
reliably, switch over to using "GROUP BY column-number" syntax rather than
"GROUP BY expression" in transmitted queries, and adjust foreign_grouping_ok()
to be more careful about duplicating the sortgroupref labeling of the local
pathtarget. Per bug #14890 from Sean Johnston. Back-patch to v10 where the
buggy code was introduced. Jeevan Chalke, reviewed by Ashutosh Bapat
Discussion:
https://postgr.es/m/20171107134948.1508.94783@wrigleys.postgresql.org
https://git.postgresql.org/pg/commitdiff/e9f2703ab7b29f7e9100807cfbd19ddebbaa0b12

Bruce Momjian pushed:

- pg_upgrade: prevent check on live cluster from generating error. Previously
an inaccurate but harmless error was generated when running --check on a live
server before reporting the servers as compatible. The fix is to split error
reporting and exit control in the exec_prog() API. Reported-by: Daniel
Westermann Backpatch-through: 10
https://git.postgresql.org/pg/commitdiff/d25ee30031b08ad1348a090914c2af6bc640a832

- Remove outdated/removed Win32 URLs in C comments. Reported-by: Ashutosh
Sharma
https://git.postgresql.org/pg/commitdiff/fccaea45496d721012ce8fbbebae82e4dbfc1ef4

- doc: add JSON acronym. Reported-by: torsten(dot)grust(at)gmail(dot)com Discussion:
https://postgr.es/m/20171024201849.1488.71071@wrigleys.postgresql.org
https://git.postgresql.org/pg/commitdiff/ca454b9bd34c75995eda4d07c9858f7c22890c2b

- C comment: fix "the the" mentions in C comments. Reported-by: Christoph
Dreis Discussion:
https://postgr.es/m/007e01d3519e$2734ca10$759e5e30$@freenet.de Author:
Christoph Dreis
https://git.postgresql.org/pg/commitdiff/bdb70c12b3a2e69eec6e51411df60d9f43ecc841

- docs: replace dblink() mention with foreign data mention. Reported-by:
steven(dot)winfield(at)cantabcapital(dot)com Discussion:
https://postgr.es/m/20171031105039.17183.850@wrigleys.postgresql.org
https://git.postgresql.org/pg/commitdiff/255f14183ac7bc6a83a5bb00d67d5ac7e8b645f1

Robert Haas pushed:

- Fix comment. RELATION_IS_OTHER_TEMP is tested in the caller, not here.
Discussion: http://postgr.es/m/5A5438E4.3090709@lab.ntt.co.jp
https://git.postgresql.org/pg/commitdiff/63008b19ee67270231694500832b031868d34428

- Don't allow VACUUM VERBOSE ANALYZE VERBOSE. There are plans to extend the
syntax for ANALYZE, so we need to break the link between VacuumStmt and
AnalyzeStmt. But apart from that, the syntax above is undocumented and, if
discovered by users, might give the impression that the VERBOSE option for
VACUUM differs from the verbose option from ANALYZE, which it does not.
Nathan Bossart, reviewed by Michael Paquier and Masahiko Sawada Discussion:
http://postgr.es/m/D3FC73E2-9B1A-4DB4-8180-55F57D116B4E@amazon.com
https://git.postgresql.org/pg/commitdiff/921059bd66c7fb1230c705d3b1a65940800c4cbb

- Add missing "return" statement to accumulate_append_subpath. Without this,
Parallel Append can end up with extra children. Report by Rajkumar
Raghuwanshi. Fix by Amit Khandekar. Brown paper bag bug by me. Discussion:
http://postgr.es/m/CAKcux6mBF-NiddyEe9LwymoUC5+wh8bQJ=uk2gGkOE+L8cv=LA@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/2fd58096f02777c38edb392f78cb5b4ebd90e9d2

Peter Eisentraut pushed:

- Fix ssl tests for when tls-server-end-point is not supported. Add a function
to TestLib that allows us to check pg_config.h and then decide the expected
test outcome based on that. Author: Michael Paquier
<michael(dot)paquier(at)gmail(dot)com>
https://git.postgresql.org/pg/commitdiff/c3d41ccf5931a2e587d114d9886717df76459a9d

- Update portal-related memory context names and API. Rename PortalMemory to
TopPortalContext, to avoid confusion with PortalContext and align naming with
similar top-level memory contexts. Rename PortalData's "heap" field to
portalContext. The "heap" naming seems quite antiquated and confusing. Also
get rid of the PortalGetHeapMemory() macro and access the field directly,
which we do for other portal fields, so this abstraction doesn't buy anything.
Reviewed-by: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> Reviewed-by:
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
https://git.postgresql.org/pg/commitdiff/0f7c49e85518dd846ccd0a044d49a922b9132983

- Remove PortalGetQueryDesc(). After having gotten rid of
PortalGetHeapMemory(), there seems little reason to keep one Portal access
macro around that offers no actual abstraction and isn't consistently used
anyway. Reviewed-by: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Reviewed-by: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
https://git.postgresql.org/pg/commitdiff/a77dd53f3089a3d6bf74966bfd3ab7e27537183b

- Give more accurate error message for dropping pinned portal. The previous
code gave the same error message for attempting to drop pinned and active
portals, but those are separate states, so give separate error messages.
https://git.postgresql.org/pg/commitdiff/acc67ffd0a8c728b928958e75b76ee544b64c2d8

- Move portal pinning from PL/pgSQL to SPI. PL/pgSQL "pins" internally
generated (unnamed) portals so that user code cannot close them by guessing
their names. This logic is also useful in other languages and really for any
code. So move that logic into SPI. An unnamed portal obtained through
SPI_cursor_open() and related functions is now automatically pinned, and
SPI_cursor_close() automatically unpins a portal that is pinned. In the core
distribution, this affects PL/Perl and PL/Python, preventing users from
manually closing cursors created by spi_query and plpy.cursor, respectively.
(PL/Tcl does not currently offer any cursor functionality.) Reviewed-by:
Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
https://git.postgresql.org/pg/commitdiff/b3617cdfbba1b5381e9d1c6bc0839500e8eb7273

- Revert "Move portal pinning from PL/pgSQL to SPI". This reverts commit
b3617cdfbba1b5381e9d1c6bc0839500e8eb7273. This broke returning unnamed
cursors from PL/pgSQL functions. Apparently, there are no test cases for
this.
https://git.postgresql.org/pg/commitdiff/b48b2f8793ef256d19274b4ef6ff587fd47ab553

- Add tests for PL/pgSQL returning unnamed portals as refcursor. Existing tests
only covered returning explicitly named portals as refcursor. The unnamed
cursor case was recently broken without a test failing.
https://git.postgresql.org/pg/commitdiff/511585417079b7d52211e09b20de0e0981b6eaa6

- Use portal pinning in PL/Perl and PL/Python. PL/pgSQL "pins" internally
generated portals so that user code cannot close them by guessing their names.
Add this functionality to PL/Perl and PL/Python as well, preventing users from
manually closing cursors created by spi_query and plpy.cursor, respectively.
(PL/Tcl does not currently offer any cursor functionality.)
https://git.postgresql.org/pg/commitdiff/70d6226e4fba26765877fc3c2ec6c468d3ff4084

- Fix Latin spelling. "c.f." should be "cf.".
https://git.postgresql.org/pg/commitdiff/9e945f862633882cae3183d465f321bd8dd591f9

- Refactor subscription tests to use PostgresNode's wait_for_catchup. This was
nearly the same code. Extend wait_for_catchup to allow waiting for
pg_current_wal_lsn() and use that in the subscription tests. Also change one
use in the pg_rewind tests to use this. Also remove some broken code in
wait_for_catchup and wait_for_slot_catchup. The error message in case the
waiting failed wanted to show the current LSN, but the way it was written
never worked. So since nobody ever cared, just remove it. Reviewed-by:
Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
https://git.postgresql.org/pg/commitdiff/bbd3363e128daec0e70952c1bb2f12ab1f6f1292

Andrew Dunstan pushed:

- Implement TZH and TZM timestamp format patterns. These are compatible with
Oracle and required for the datetime template language for jsonpath in an
upcoming patch. Nikita Glukhov and Andrew Dunstan, reviewed by Pavel Stehule.
https://git.postgresql.org/pg/commitdiff/11b623dd0a2c385719ebbbdd42dd4ec395dcdc9d

Álvaro Herrera pushed:

- Change some bogus PageGetLSN calls to BufferGetLSNAtomic. As
src/backend/access/transam/README says, PageGetLSN may only be called by
processes holding either exclusive lock on buffer, or a shared lock on buffer
plus buffer header lock. Therefore any place that only holds a shared buffer
lock must use BufferGetLSNAtomic instead of PageGetLSN, which internally
obtains buffer header lock prior to reading the LSN. A few callsites failed
to comply with this rule. This was detected by running all tests under a new
(not committed) assertion that verifies PageGetLSN locking contract. All but
one of the callsites that failed the assertion are fixed by this patch.
Remaining callsites were inspected manually and determined not to need any
change. The exception (unfixed callsite) is in TestForOldSnapshot, which only
has a Page argument, making it impossible to access the corresponding Buffer
from it. Fixing that seems a much larger patch that will have to be done
separately; and that's just as well, since it was only introduced in 9.6 and
other bugs are much older. Some of these bugs are ancient; backpatch all the
way back to 9.3. Authors: Jacob Champion, Asim Praveen, Ashwin Agrawal
Reviewed-by: Michaël Paquier Discussion:
https://postgr.es/m/CABAq_6GXgQDVu3u12mK9O5Xt5abBZWQ0V40LZCE+oUf95XyNFg@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/272c2ab9fd0a604e3200030b1ea26fd464c44935

- Remove hard-coded schema knowledge about pg_attribute from genbki.pl. Add the
ability to label a column's default value in the catalog header, and implement
this for pg_attribute. A new function in Catalog.pm is used to fill in a
tuple with defaults. The build process will complain loudly if a catalog
entry is incomplete, Commit 8137f2c3232 labeled variable length columns for
the C preprocessor. Expose that label to genbki.pl so we can exclude those
columns from schema macros in a general fashion. Also, format schema macro
entries according to their types. This means slightly less code maintenance,
but more importantly it's a proving ground for mechanisms intended to be used
in later commits. While at it, I (Álvaro) couldn't resist making some changes
in genbki.pl: rename some functions to actually indicate their purpose instead
of actively misleading onlookers; and don't iterate on the whole of pg_type to
find the entry for each catalog row, using a hash instead of an array.
Author: John Naylor, some changes by Álvaro Herrera Discussion:
https://postgr.es/m/CAJVSVGVJHwD8sfDfZW9TbCHWKf=C1YDRM-rF=2JenRU_y+VcFg@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/49c784ece766781250224a371be14af71e7eda93

Andres Freund pushed:

- Expression evaluation based aggregate transition invocation. Previously
aggregate transition and combination functions were invoked by special case
code in nodeAgg.c, evaluating input and filters separately using the
expression evaluation machinery. That turns out to not be great for
performance for several reasons: - repeated expression evaluations have some
cost - the transition functions invocations are poorly predicted, as commonly
there are multiple aggregates in a query, resulting in the same call-stack
invoking different functions. - filter and input computation had to be done
separately - the special case code made it hard to implement JITing of the
whole transition function invocation Address this by building one large
expression that computes input, evaluates filters, and invokes transition
functions. This leads to moderate speedups in queries bottlenecked by
aggregate computations, and enables large speedups for similar cases once
JITing is done. There's potential for further improvement: - It'd be nice if
we could simplify the somewhat expensive aggstate->all_pergroups lookups. -
right now there's still an advance_transition_function invocation in
nodeAgg.c, leading to some code duplication. Author: Andres Freund
Discussion:
https://postgr.es/m/20170901064131.tazjxwus3k2w3ybh@alap3.anarazel.de
https://git.postgresql.org/pg/commitdiff/69c3936a1499b772a749ae629fc59b2d72722332

Teodor Sigaev pushed:

- Fix allowing of leading zero on exponents in pgbench test results. Commit
bc7fa0c15c590ddf4872e426abd76c2634f22aca accidentally lost fixes of
0aa1d489ea756b96b6d5573692ae9cd5d143c2a5 commit. Thanks to Thomas Munro
https://git.postgresql.org/pg/commitdiff/d16c2de6244f3b71c0c77a3d63905227fdc78428

- Improve scripting language in pgbench. Added: - variable now might contain
integer, double, boolean and null values - functions ln, exp - logical
AND/OR/NOT - bitwise AND/OR/NOT/XOR - bit right/left shift - comparison
operators - IS [NOT] (NULL|TRUE|FALSE) - conditional choice (in form of
when/case/then) New operations and functions allow to implement more
complicated test scenario. Author: Fabien Coelho with minor editorization by
me Reviewed-By: Pavel Stehule, Jeevan Ladhe, me Discussion:
https://www.postgresql.org/message-id/flat/alpine(dot)DEB(dot)2(dot)10(dot)1604030742390(dot)31618(at)sto
https://git.postgresql.org/pg/commitdiff/bc7fa0c15c590ddf4872e426abd76c2634f22aca

- Fix behavior of ~> (cube, int) operator. ~> (cube, int) operator was
especially designed for knn-gist search. However, it appears that knn-gist
search can't work correctly with current behavior of this operator when
dataset contains cubes of variable dimensionality. In this case, the same
value of second operator argument can point to different dimension depending
on dimensionality of particular cube. Such behavior is incompatible with gist
indexing of cubes, and knn-gist doesn't work correctly for it. This patch
changes behavior of ~> (cube, int) operator by introducing dimension numbering
where value of second argument unambiguously identifies number of dimension.
With new behavior, this operator can be correctly supported by knn-gist.
Relevant changes to cube operator class are also included. Backpatch to v9.6
where operator was introduced. Since behavior of ~> (cube, int) operator is
changed, depending entities must be refreshed after upgrade. Such as,
expression indexes using this operator must be reindexed, materialized views
must be rebuilt, stored procedures and client code must be revised to
correctly use new behavior. That should be mentioned in release notes.
Noticed by: Tomas Vondra Author: Alexander Korotkov Reviewed by: Tomas Vondra,
Andrey Borodin Discussion:
https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292(at)2ndquadrant(dot)com
https://git.postgresql.org/pg/commitdiff/563a053bdd4b91c5e5560f4bf91220e562326f7d

- Allow negative coordinate for ~> (cube, int) operator. ~> (cube, int)
operator was especially designed for knn-gist search. However, knn-gist
supports only ascending ordering of results. Nevertheless it would be useful
to support descending ordering by ~> (cube, int) operator. We provide
workaround for that: negative coordinate give us inversed value of
corresponding cube bound. Therefore, knn search using negative coordinate
gives us an effect of descending ordering by cube bound. Author: Alexander
Korotkov Reviewed by: Tomas Vondra, Andrey Borodin Discussion:
https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292(at)2ndquadrant(dot)com
https://git.postgresql.org/pg/commitdiff/f50c80dbb17efa39c169f6c510e9464486ff5edc

Michael Meskes pushed:

- Fix parsing of compatibility mode argument. Patch by Ashutosh Sharma
<ashu(dot)coek88(at)gmail(dot)com>
https://git.postgresql.org/pg/commitdiff/ca4587f3f94f5c33da6543535f666a9f20f3ef33

- Cope with indicator arrays that do not have the correct length. Patch by:
"Rader, David" <davidr(at)openscg(dot)com>
https://git.postgresql.org/pg/commitdiff/649aeb123f73e69cf78c52b534c15c51a229d63d

== Pending Patches ==

Alexander Korotkov sent in another revision of a patch to implement incremental
sort.

Shubham Barai sent in three more revisions of a patch to implement predicate
locking for GiST indexes.

Haribabu Kommi sent in a patch to add a new libpq API, PQeffectiveconninfo,
which is similar to PQconninfo. It provides the effectively used connection
options in the current connection. An accompanying patch uses the API to add
effective an conninfo column to pg_stat_wal_receiver.

Catalin Iacob sent in a patch to document huge_pages better.

Álvaro Herrera sent in three more revisions of a patch to implement local
indexes on partitioned tables.

Michaël Paquier sent in a patch to clarify the hostaddrs part of the libpq
documentation.

Masahiko Sawada sent in another revision of a patch to fix an bug in the slot
error callback.

Haribabu Kommi sent in another revision of a patch to implement pluggable
storage.

Peter Eisentraut sent in a patch to add a prokind column, replacing proisagg and
proiswindow and update pg_proc.h with this change.

Andres Freund sent in a patch to implement grouping equality using expressions,
a step towards JITing same.

Chapman Flack and Fabien COELHO traded patches to enable setting random seeds in
pgbench.

Alexander Korotkov sent in two more revisions of a patch to implement 64-bit
XIDs.

Ildar Musin and Fabien COELHO traded patches to implement a general purpose
hashing function in pgbench.

David Rowley sent in another revision of a patch to implement runtime partition
pruning.

Yuqi Gu sent in a patch to make crc32 more efficient on the ARM64 architecture.

Aleksandr Parfenov sent in another revision of a patch to make full text search
configuration more flexible.

Fabien COELHO sent in a patch to fix an issue with pgbench on Windows.

Fabien COELHO sent in another revision of a patch to enable pgbench to store
query results as variables.

Konstantin Knizhnik sent in another revision of a patch to improve non-injective
functional indexes.

Fabien COELHO sent in a patch to fix a typo in a pgbench TAP test.

Konstantin Knizhnik sent in another revision of a patch to implement AS OF
queries.

Nikita Glukhov sent in another revision of a patch to implement JSONPATH.

Nikita Glukhov sent in a patch to implement JSON functions per SQL:2016.

Nathan Bossart sent in another revision of a patch to add a NOWAIT option to
VACUUM and add a parenthesized option syntax to ANALYZE.

Julian Markwort sent in another revision of a patch to enable pg_stat_statements
to track poor plans.

Haribabu Kommi sent in two revisions of a patch to ensure that PQhost returns
correct host details.

Fabien COELHO sent in another revision of a patch to add \if to pgbench.

Jeff Davis sent in another revision of a patch to implement range merge joins.

Daniel Gustafsson sent in two more revisions of a patch to use strcmp() instead
of pg_strcasecmp() for identifier matching and avoid silently changing
volatility in CREATE FUNCTION.

Amit Khandekar sent in another revision of a patch to make updates to
partition keys that would have the effect of moving tuples to another partition
Just Work™.

Nikita Glukhov sent in another revision of a patch to implement JSON_TABLE.

Etsuro Fujita sent in another revision of a patch to allow pushing more UPDATE
quals to the PostgreSQL FDW.

Kyotaro HORIGUCHI sent in another revision of a patch to fix a WAL logging
problem.

Kyotaro HORIGUCHI sent in another revision of a patch to implement asynchronous
execution in general and in the PostgreSQL FDW in particular.

Jeevan Chalke sent in another revision of a patch to implement partition-wise
aggregation/grouping.

Konstantin Knizhnik sent in another revision of a patch to optimize secondary
indexes.

Kyotaro HORIGUCHI sent in another revision of a patch to allow limiting the
resources logical replication uses by adding a WAL relief valve for replication
slots, a monitoring aid for max_replication_slots, TAP tests for the slot
limiting feature, and document documentation for same.

Álvaro Herrera sent in another revision of a patch to implement unique indexes
on partitioned tables.

Tsutomu Yamada sent in a patch to change estimate_path_cost_size in postgres_fdw
to refer to foreignrel instead of baserel.

Tsutomu Yamada sent in a patch to add queryEnv to ExplainOneQuery_hook.

Stephen Frost sent in two more revisions of a patch to remove the redundant
IndexTupleDSize macro.

Christian Rossow sent in a patch to implement bitwise logical operations
implementation (xor / and / or / not) for bytea.

Amit Langote and David Rowley traded patches to speed up partition pruning.

Thomas Munro sent in another revision of a patch to add plan count and time to
pg_stat_statements.

Vaishnavi Prabakaran sent in another revision of a patch to add batch/pipelining
support to libpq.

Michaël Paquier sent in a patch to ensure that pg_get_functiondef remembers all
GUC_LIST_INPUT GUCs.

Michaël Paquier sent in a patch to refactor the syscache routines to get
attribute name, extend lookup routines for FDW and foreign server with NULL
handling, refactor routines for subscription and publication lookups, and
eliminate user-visible cache lookup errors for objaddr SQL functions.

Edmund Horner sent in another revision of a patch to add tab completion to
SELECT in psql.

Amul Sul sent in another revision of a patch to see to it that when a tuple is
being moved to another partition, the ip_blkid in the tuple header is set to
InvalidBlockNumber and add isolation tests for same.

Konstantin Knizhnik sent in another revision of a patch to auto-prepare.

Artur Zakirov sent in a patch to fix a bug in to_timestamp() where it would,
under some circumstances, ignore a '-' character it should have taken into
account.

Anthony Bykov sent in another revision of a patch to implement JSONB transforms
for PL/PythonU.

Etsuro Fujita sent in another revision of a patch to add an eqpath for
foreignjoin.

Robert Haas sent in a patch to sort the epq path if needed.

Álvaro Herrera sent in another revision of a patch to implement foreign key
arrays.

Tomas Vondra sent in another revision of a patch to implement multivariate
histograms and MCV lists.

Anthony Bykov sent in another revision of a patch to implement transforms for
JSONB for PL/Perl.

Ildar Musin sent in a patch to add random_zipfian function to the paragraph in
pgbench documentation about random functions parameterization.

Curt Tilmes sent in a patch to find additional connection service files in
a newly invented pg_service.conf.d directory.

John Naylor sent in two more revisions of a patch to refactor how bootstrap data
is stored in source and handled.

Haribabu Kommi sent in a patch to define a previously undefined behavior when
the PQHost() connect string contains both host and hostaddr types.