== PostgreSQL Weekly News - August 19 2018 ==

== PostgreSQL Weekly News - August 19 2018 ==

== PostgreSQL Product News ==

Ora2Pg 19.0, a tool for migrating Oracle databases to PostgreSQL, released.
http://ora2pg.darold.net/

Ajqvue Version 2.0, a java-based UI which supports PostgreSQL, released.
http://ajqvue.com

pgbouncer 1.9.0, a connection pooler and more for PostgreSQL, released.
https://pgbouncer.github.io/2018/08/pgbouncer-1-9-0

== PostgreSQL Jobs for August ==

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

== PostgreSQL Local ==

PostgreOpen Silicon Valley 2018 will be held in San Francisco on September 5-7, 2018.
https://2018.postgresopen.org/

The Portland PostgreSQL Users Group will be holding a PGDay on September 10,
2018 in Portland, OR. The CfP is open at https://goo.gl/forms/E0CiUQGSZGMYwh922
https://pdx.postgresql.us/pdxpgday2018

PostgresConf South Africa 2018 will take place in Johannesburg on October 9, 2018
https://postgresconf.org/conferences/SouthAfrica2018

PostgreSQL Conference Europe 2018 will be held on October 23-26, 2018 at the
Lisbon Marriott Hotel in Lisbon, Portugal.
https://2017.pgconf.eu/

2Q PGConf will be on December 4-5, 2018 in Chicago, IL. The CfP is open through
August 27, 2018 at midnight Pacific Time at http://www.2qpgconf.com/#cfp
http://www.2qpgconf.com/

PGConf.ASIA 2018 will take place on December 10-12, 2018 in Akihabara, Tokyo,
Japan.
http://www.pgconf.asia/EN/2018/

== 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 PST8PDT to david(at)fetter(dot)org(dot)

== Applied Patches ==

Tom Lane pushed:

- Revert "Distinguish printf-like functions that support %m from those that
don't.". This reverts commit 3a60c8ff892a8242b907f44702bfd9f1ff877d45.
Buildfarm results show that that caused a whole bunch of new warnings on
platforms where gcc believes the local printf to be non-POSIX-compliant. This
problem outweighs the hypothetical-anyway possibility of getting warnings for
misuse of %m. We could use gnu_printf archetype when we've substituted
src/port/snprintf.c, but that brings us right back to the problem of not
getting warnings for %m. A possible answer is to attack it in the other
direction by insisting that %m support be included in printf's feature set,
but that will take more investigation. In the meantime, revert the previous
change, and update the comment for PGAC_C_PRINTF_ARCHETYPE to more fully
explain what's going on. Discussion:
https://postgr.es/m/2975.1526862605@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/46b5e7c4b5befbf6ac86d827a3a58f1f02c7338e

- Fix bogus loop logic in 013_crash_restart test's pump_until subroutine. The
pump_nb() step might've already received the desired data, so we must check
for that at the top of the loop not the bottom. Otherwise, the call to pump()
will sit with nothing to do until the timeout elapses. pump_until then falls
out with apparent success ... but the timeout has been used up, causing the
next call of pump_until to report a timeout failure. I believe this explains
the intermittent timeout failures we've seen in the buildfarm ever since this
test went in. I was able to reproduce the problem on gaur semi-repeatably,
and this appears to fix it. In passing, remove a duplicate assignment, fix
one stdin-assignment to look like the rest, and document the test's dependency
on test_decoding.
https://git.postgresql.org/pg/commitdiff/d11eae09e48694ad6b4139bbb7d7b112833301f5

- Fix libpq's implementation of per-host connection timeouts. Commit 5f374fe7a
attempted to turn the connect_timeout from an overall maximum time limit into
a per-host limit, but it didn't do a great job of that. The timer would only
get restarted if we actually detected timeout within connectDBComplete(), not
if we changed our attention to a new host for some other reason. In that case
the old timeout continued to run, possibly causing a premature timeout failure
for the new host. Fix that, and also tweak the logic so that if we do get a
timeout, we advance to the next available IP address, not to the next host
name. There doesn't seem to be a good reason to assume that all the IP
addresses supplied for a given host name will necessarily fail the same way as
the current one. Moreover, this conforms better to the admittedly-vague
documentation statement that the timeout is "per connection attempt". I
changed that to "per host name or IP address" to be clearer. (Note that
reconnections to the same server, such as for switching protocol version or
SSL status, don't get their own separate timeout; that was true before and
remains so.) Also clarify documentation about the interpretation of
connect_timeout values less than 2. This seems like a bug, so back-patch to
v10 where this logic came in. Tom Lane, reviewed by Fabien Coelho Discussion:
https://postgr.es/m/5735.1533828184@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/1e6e98f7638904b2aa4df0bd87064239ce9d8fcf

- Remove duplicate function declarations. Christoph Berg Discussion:
https://postgr.es/m/20180814165536.GB21152@msg.df7cb.de
https://git.postgresql.org/pg/commitdiff/02dc7466baed074f7833bd6fd1067e23e1bfa1dd

- Make snprintf.c follow the C99 standard for snprintf's result value. C99 says
that the result should be the number of bytes that would have been emitted
given a large enough buffer, not the number we actually were able to put in
the buffer. It's time to make our substitute implementation comply with that.
Not doing so results in inefficiency in buffer-enlargement cases, and also
poses a portability hazard for third-party code that might expect
C99-compliant snprintf behavior within Postgres. In passing, remove useless
tests for str == NULL; neither C99 nor predecessor standards ever allowed that
except when count == 0, so I see no reason to expend cycles on making that a
non-crash case for this implementation. Also, don't waste a byte in
pg_vfprintf's local I/O buffer; this might have performance benefits by
allowing aligned writes during flushbuffer calls. Discussion:
https://postgr.es/m/17245.1534289329@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/805889d7d23fbecf5925443deb334aaeb6beaeb0

- Clean up assorted misuses of snprintf()'s result value. Fix a small number of
places that were testing the result of snprintf() but doing so incorrectly.
The right test for buffer overrun, per C99, is "result >= bufsize" not "result
> bufsize". Some places were also checking for failure with "result == -1",
but the standard only says that a negative value is delivered on failure.
(Note that this only makes these places correct if snprintf() delivers
C99-compliant results. But at least now these places are consistent with all
the other places where we assume that.) Also, make psql_start_test() and
isolation_start_test() check for buffer overrun while constructing their shell
commands. There seems like a higher risk of overrun, with more severe
consequences, here than there is for the individual file paths that are made
elsewhere in the same functions, so this seemed like a worthwhile change.
Also fix guc.c's do_serialize() to initialize errno = 0 before calling
vsnprintf. In principle, this should be unnecessary because vsnprintf should
have set errno if it returns a failure indication ... but the other two
places this coding pattern is cribbed from don't assume that, so let's be
consistent. These errors are all very old, so back-patch as appropriate. I
think that only the shell command overrun cases are even theoretically
reachable in practice, but there's not much point in erroneous error checks.
Discussion: https://postgr.es/m/17245.1534289329@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/cc4f6b77861803be99dfc17a38052035a0af5ae6

- Require a C99-compliant snprintf(), and remove related workarounds. Since our
substitute snprintf now returns a C99-compliant result, there's no need
anymore to have complicated code to cope with pre-C99 behavior. We can just
make configure substitute snprintf.c if it finds that the system snprintf() is
pre-C99. (Note: I do not believe that there are any platforms where this test
will trigger that weren't already being rejected due to our other C99-ish
feature requirements for snprintf. But let's add the check for paranoia's
sake.) Then, simplify the call sites that had logic to cope with the pre-C99
definition. I also dropped some stuff that was being paranoid about the
possibility of snprintf overrunning the given buffer. The only reports we've
ever heard of that being a problem were for Solaris 7, which is long dead, and
we've sure not heard any reports of these assertions triggering in a long
time. So let's drop that complexity too. Likewise, drop some code that
wasn't trusting snprintf to set errno when it returns -1. That would be
not-per-spec, and again there's no real reason to believe it is a live issue,
especially not for snprintfs that pass all of configure's feature checks.
Discussion: https://postgr.es/m/17245.1534289329@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/e1d19c902e59ad739cb4b6267ee2073a61e86cd3

- Fix configure's snprintf test so it exposes HP-UX bug. Since commit
e1d19c902, buildfarm member gharial has been failing with symptoms indicating
that snprintf sometimes returns -1 for buffer overrun, even though it passes
the added configure check. Some google research suggests that this happens
only in limited cases, such as when the overrun happens partway through a %d
item. Adjust the configure check to exercise it that way. Since I'm now
feeling more paranoid than I was before, also make the test explicitly verify
that the buffer doesn't get physically overrun.
https://git.postgresql.org/pg/commitdiff/9bed827b18cc4f27fb7cd7c02ad301519eca6d29

- Ensure schema qualification in pg_restore DISABLE/ENABLE TRIGGER commands.
Previously, this code blindly followed the common coding pattern of passing
PQserverVersion(AH->connection) as the server-version parameter of
fmtQualifiedId. That works as long as we have a connection; but in pg_restore
with text output, we don't. Instead we got a zero from PQserverVersion, which
fmtQualifiedId interpreted as "server is too old to have schemas", and so the
name went unqualified. That still accidentally managed to work in many cases,
which is probably why this ancient bug went undetected for so long. It only
became obvious in the wake of the changes to force dump/restore to execute
with restricted search_path. In HEAD/v11, let's deal with this by ripping out
fmtQualifiedId's server- version behavioral dependency, and just making it
schema-qualify all the time. We no longer support pg_dump from servers old
enough to need the ability to omit schema name, let alone restoring to them.
(Also, the few callers outside pg_dump already didn't work with pre-schema
servers.) In older branches, that's not an acceptable solution, so instead
just tweak the DISABLE/ENABLE TRIGGER logic to ensure it will schema-qualify
its output regardless of server version. Per bug #15338 from Oleg somebody.
Back-patch to all supported branches. Discussion:
https://postgr.es/m/153452458706.1316.5328079417086507743@wrigleys.postgresql.org
https://git.postgresql.org/pg/commitdiff/6771c932cf5a8bbb8219461066987ad3b11688ff

- Doc: remove obsolete advice about manually inserting snprintf into build.
This para is obsolete, first because nobody is using Solaris 7 anymore, and
second because if someone was, configure should catch the snprintf buffer
overrun problem automatically (since commit 9bed827b1), and third because this
is incorrect advice about how to manually force use of snprintf.c anyway, and
has been so at least since commit 3bc6bdf32. The lack of complaints about it
reinforces the conclusion that Solaris 7 no longer exists in the wild; so I
don't feel a need to insert correct advice instead.
https://git.postgresql.org/pg/commitdiff/47183265ed745d9ee7e0ac0798a5c88660436d4e

Andrew Gierth pushed:

- Avoid query-lifetime memory leaks in XMLTABLE (bug #15321). Multiple calls to
XMLTABLE in a query (e.g. laterally applying it to a table with an xml column,
an important use-case) were leaking large amounts of memory into the per-query
context, blowing up memory usage. Repair by reorganizing memory context usage
in nodeTableFuncscan; use the usual per-tuple context for row-by-row
evaluations instead of perValueCxt, and use the explicitly created context --
renamed from perValueCxt to perTableCxt -- for arguments and state for each
individual table-generation operation. Backpatch to PG10 where this code was
introduced. Original report by IRC user begriffs; analysis and patch by me.
Reviewed by Tom Lane and Pavel Stehule. Discussion:
https://postgr.es/m/153394403528.10284.7530399040974170549@wrigleys.postgresql.org
https://git.postgresql.org/pg/commitdiff/07172d5aff8f43cd6ce09f57a0b56a535d7eaf45

- Set scan direction appropriately for SubPlans (bug #15336). When executing a
SubPlan in an expression, the EState's direction field was left alone,
resulting in an attempt to execute the subplan backwards if it was encountered
during a backwards scan of a cursor. Also, though much less likely, it was
possible to reach the execution of an InitPlan while in backwards-scan state.
Repair by saving/restoring estate->es_direction and forcing forward scan mode
in the relevant places. Backpatch all the way, since this has been broken
since 8.3 (prior to commit c7ff7663e, SubPlans had their own EStates rather
than sharing the parent plan's, so there was no confusion over scan
direction). Per bug #15336 reported by Vladimir Baranoff; analysis and patch
by me, review by Tom Lane. Discussion:
https://postgr.es/m/153449812167.1304.1741624125628126322@wrigleys.postgresql.org
https://git.postgresql.org/pg/commitdiff/520acab171244b55d816c70b9a89280b09937925

Amit Kapila pushed:

- Prohibit shutting down resources if there is a possibility of back up.
Currently, we release the asynchronous resources as soon as it is evident that
no more rows will be needed e.g. when a Limit is filled. This can be
problematic especially for custom and foreign scans where we can scan
backward. Fix that by disallowing the shutting down of resources in such
cases. Reported-by: Robert Haas Analysed-by: Robert Haas and Amit Kapila
Author: Amit Kapila Reviewed-by: Robert Haas Backpatch-through: 9.6 where this
code was introduced Discussion:
https://postgr.es/m/86137f17-1dfb-42f9-7421-82fd786b04a1@anayrat.info
https://git.postgresql.org/pg/commitdiff/2cd0acfdade82f3cab362fd9129d453f81cc2745

- Adjust comment atop ExecShutdownNode. After commits a315b967cc and
b805b63ac2, part of the comment atop ExecShutdownNode is redundant. Adjust
it. Author: Amit Kapila Backpatch-through: 10 where both the mentioned
commits are present. Discussion:
https://postgr.es/m/86137f17-1dfb-42f9-7421-82fd786b04a1@anayrat.info
https://git.postgresql.org/pg/commitdiff/4f9a97e417ca3c162c2c83918873e3ac2cf0ace4

Michaël Paquier pushed:

- Make autovacuum more aggressive to remove orphaned temp tables. Commit
dafa084, added in 10, made the removal of temporary orphaned tables more
aggressive. This commit makes an extra step into the aggressiveness by adding
a flag in each backend's MyProc which tracks down any temporary namespace
currently in use. The flag is set when the namespace gets created and can be
reset if the temporary namespace has been created in a transaction or
sub-transaction which is aborted. The flag value assignment is assumed to be
atomic, so this can be done in a lock-less fashion like other flags already
present in PGPROC like databaseId or backendId, still the fact that the
temporary namespace and table created are still locked until the transaction
creating those commits acts as a barrier for other backends. This new flag
gets used by autovacuum to discard more aggressively orphaned tables by
additionally checking for the database a backend is connected to as well as
its temporary namespace in-use, removing orphaned temporary relations even if
a backend reuses the same slot as one which created temporary relations in a
past session. The base idea of this patch comes from Robert Haas, has been
written in its first version by Tsunakawa Takayuki, then heavily reviewed by
me. Author: Tsunakawa Takayuki Reviewed-by: Michael Paquier, Kyotaro
Horiguchi, Andres Freund Discussion:
https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8A4DC6@G01JPEXMBYT05
Backpatch: 11-, as PGPROC gains a new flag and we don't want silent ABI
breakages on already released versions.
https://git.postgresql.org/pg/commitdiff/246a6c8f7b237cc1943efbbb8a7417da9288f5c4

- Update comment in header of errcodes.txt. This file mentions all the files
generated from it, but missed that errcodes-list.sgml is no more, while
errcodes-table.sgml is. Author: Noriyoshi Shinoda Discussion:
https://postgr.es/m/TU4PR8401MB0430855D6B971E49EB55F328EE3E0@TU4PR8401MB0430.NAMPRD84.PROD.OUTLOOK.COM
https://git.postgresql.org/pg/commitdiff/3593579bcdc77a70e0f987dca6d47f0bf1337f76

- Mention ownership requirements for REFRESH MATERIALIZED VIEW in docs. Author:
Dian Fay Discussion:
https://postgr.es/m/745abbd2-a1a0-ead8-2cb2-768c16747d97@gmail.com
Backpatch-through: 9.3
https://git.postgresql.org/pg/commitdiff/ee80124811908ef1d4679296c46e36bd8a32b9de

Peter Eisentraut pushed:

- Remove obsolete comment. The sequence name is no longer stored in the
sequence relation, since 1753b1b027035029c2a2a1649065762fafbf63f3.
https://git.postgresql.org/pg/commitdiff/3ebdd21b794b49fde2010ff3d39071e02d27b404

- Remove obsolete linux dynloader code. This has been obsolete probably since
the late 1990s.
https://git.postgresql.org/pg/commitdiff/351855fc4ebc2b5e62565f63ddbedbcada80e532

- Remove obsolete openbsd dynloader code. dlopen() has been documented since
OpenBSD 2.0 (1996).
https://git.postgresql.org/pg/commitdiff/29351a06af5b14b8f5efca18f5ec58f56eb33f2b

- Remove obsolete netbsd dynloader code. dlopen() has been documented since
NetBSD 1.1 (1995).
https://git.postgresql.org/pg/commitdiff/b68ff3ea672c066b7eee6ca777618025b40abfd4

- Remove obsolete darwin dynloader code. not needed since macOS 10.3 (2003)
https://git.postgresql.org/pg/commitdiff/b5d29299ccad9b2385236f2b82a0c4e1365b9add

- Remove obsolete freebsd dynloader code. dlopen() has been documented since
FreeBSD 3.0 (1989).
https://git.postgresql.org/pg/commitdiff/2db1905fdde019115e7c536dd98e1adeb8a0fa3a

- doc: Update broken links. Discussion:
https://www.postgresql.org/message-id/flat/153044458767.13254.16049977382403131287%40wrigleys.postgresql.org
https://git.postgresql.org/pg/commitdiff/6f1591955db0a30f701ab10ea40cefeca6ff9b3f

- Remove unused configure test for ldopen(). unused since
f2cc453dd7e87e800a62a173dea0353bf106668d
https://git.postgresql.org/pg/commitdiff/9d0aa4f4d22a4feddbf7c05308fe32b32d14c13f

- InsertPgAttributeTuple() to set attcacheoff. InsertPgAttributeTuple() is the
interface between in-memory tuple descriptors and on-disk pg_attribute, so it
makes sense to give it the job of resetting attcacheoff. This avoids having
all the callers having to do so. Reviewed-by: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
https://git.postgresql.org/pg/commitdiff/e4597ee65d683e11a57a4b7f597807ebf44b6cf1

- Improve error messages for CREATE OR REPLACE PROCEDURE. Change the hint to
recommend DROP PROCEDURE instead of FUNCTION. Also make the error message
when changing the return type more specific to the case of procedures.
Reported-by: Jeremy Evans <code(at)jeremyevans(dot)net> Reviewed-by: Tom Lane
<tgl(at)sss(dot)pgh(dot)pa(dot)us>
https://git.postgresql.org/pg/commitdiff/d83423db869900ffa2470826de5f8255d45ff9c6

Bruce Momjian pushed:

- pg_upgrade: fix shutdown check for standby servers. Commit
244142d32afd02e7408a2ef1f249b00393983822 only tested for the pg_controldata
output for primary servers, but standby servers have different "Database
cluster state" output, so check for that too. Diagnosed-by: Michael Paquier
Discussion: https://postgr.es/m/20180810164240.GM13638@paquier.xyz
Backpatch-through: 9.3
https://git.postgresql.org/pg/commitdiff/777e6ddf1723306bd2bf8fe6f804863f459b0323

- pg_upgrade: issue helpful error message for use on standbys. Commit
777e6ddf1723306bd2bf8fe6f804863f459b0323 checked for a shut down message from
a standby and allowed it to continue. This patch reports a helpful error
message in these cases, suggesting to use rsync as documented. Diagnosed-by:
Martín Marqués Discussion:
https://postgr.es/m/CAPdiE1xYCow-reLjrhJ9DqrMu-ppNq0ChUUEvVdxhdjGRD5_eA@mail.gmail.com
Backpatch-through: 9.3
https://git.postgresql.org/pg/commitdiff/b94f7b5350e97ef0587c0c64aed6eb940d964c06

Álvaro Herrera pushed:

- Update FSM on WAL replay of page all-visible/frozen. We aren't very strict
about keeping FSM up to date on WAL replay, because per-page freespace values
aren't critical in replicas (can't write to heap in a replica; and if the
replica is promoted, the values would be updated by VACUUM anyway). However,
VACUUM since 9.6 can skip processing pages marked all-visible or all-frozen,
and if such pages are recorded in FSM with wrong values, those values are
blindly propagated to FSM's upper layers by VACUUM's FreeSpaceMapVacuum.
(This rationale assumes that crashes are not very frequent, because those
would cause outdated FSM to occur in the primary.) Even when the FSM is
outdated in standby, things are not too bad normally, because, most per-page
FSM values will be zero (other than those propagated with the base-backup that
created the standby); only once the remaining free space is less than
0.2*BLCKSZ the per-page value is maintained by WAL replay of heap ins/upd/del.
However, if wal_log_hints=on causes complete FSM pages to be propagated to a
standby via full-page images, many too-optimistic per-page values can end up
being registered in the standby. Incorrect per-page values aren't critical in
most cases, since an inserter that is given a page that doesn't actually
contain the claimed free space will update FSM with the correct value, and
retry until it finds a usable page. However, if there are many such updates
to do, an inserter can spend a long time doing them before a usable page is
found; in a heavily trafficked insert-only table with many concurrent
inserters this has been observed to cause several second stalls, causing
visible application malfunction. To fix this problem, it seems sufficient to
have heap_xlog_visible (replay of setting all-visible and all-frozen VM bits
for a heap page) update the FSM value for the page being processed. This
fixes the per-page counters together with making the page skippable to vacuum,
so when vacuum does FreeSpaceMapVacuum, the values propagated to FSM upper
layers are the correct ones, avoiding the problem. While at it, apply the
same fix to heap_xlog_clean (replay of tuple removal by HOT pruning and
vacuum). This makes any space freed by the cleaning available earlier than
the next vacuum in the promoted replica. Backpatch to 9.6, where this problem
was diagnosed on an insert-only table with all-frozen pages, which were
introduced as a concept in that release. Theoretically it could apply with
all-visible pages to older branches, but there's been no report of that and it
doesn't backpatch cleanly anyway. Author: Álvaro Herrera
<alvherre(at)alvh(dot)no-ip(dot)org> Discussion:
https://postgr.es/m/20180802172857.5skoexsilnjvgruk@alvherre.pgsql
https://git.postgresql.org/pg/commitdiff/ab7dbd681c54d993fc8ebf8a413668fd75a4be0b

- Fix executor prune failure when plan already pruned. In a multi-layer
partitioning setup, if at plan time all the sub-partitions are pruned but the
intermediate one remains, the executor later throws a spurious error that
there's nothing to prune. That is correct, but there's no reason to throw an
error. Therefore, don't. Reported-by: Andreas Seltenreich
<seltenreich(at)gmx(dot)de> Author: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Discussion: https://postgr.es/m/87in4h98i0.fsf@ansel.ydns.eu
https://git.postgresql.org/pg/commitdiff/1eb9221585c25cad1a563bc3414f697dae3fbc8b

Thomas Munro pushed:

- Improve comment in GetNewObjectId(). The previous comment gave the impression
that skipping OIDs before FirstNormalObjectId was merely an optimization to
avoid likely collisions. In fact other parts of the system have been relying
on this threshold to detect system-created objects since commit 8e18d04d4da,
so adjust the wording. Author: Thomas Munro Reviewed-by: Tom Lane Discussion:
https://postgr.es/m/CAEepm%3D33JASACeOayr_W3%3DCSjy2jiPxM-k89axu0akFbHdjnjA%40mail.gmail.com
https://git.postgresql.org/pg/commitdiff/ca1e64febaf57eb5f3f24340c5bcce5430cad7a5

- Proof-reading for documentation. Somebody accidentally a word. Back-patch to
9.6. Reported-by: Justin Pryzby Discussion:
https://postgr.es/m/20180816195431.GA23707%40telsasoft.com
https://git.postgresql.org/pg/commitdiff/96e98fa2606b2b12805db99196f468152312af14

Andres Freund pushed:

- Try to enable C99 in configure, but do not rely on it (yet). Based on recent
discussion it seems possible that we might start to rely on more of C99. A
prerequisite for that is enabling support for that on used compilers. Let's
see on which buildfarm members autoconf's AC_PROG_CC_C99() is sufficient to do
so. There's probably at least one member where the compiler is too old, but
that'd probably be OK. If we go for this permanently we'd likely want to
clean out / up a few other configure tests. Note this does not touch the msvc
build infrastructure, which'd need separate treatment. Discussion:
https://postgr.es/m/20180815222401.kxsupl5zie2jgi4x@alap3.anarazel.de
https://git.postgresql.org/pg/commitdiff/86d78ef50e0195f8181f2b0bd9540f4ddfb73480

Tomáš Vondra pushed:

- Close the file descriptor in ApplyLogicalMappingFile. The function was
forgetting to close the file descriptor, resulting in failures like this:
ERROR: 53000: exceeded maxAllocatedDescs (492) while trying to open file
"pg_logical/mappings/map-4000-4eb-1_60DE1E08-5376b5-537c6b" LOCATION:
OpenTransientFile, fd.c:2161 Simply close the file at the end, and backpatch
to 9.4 (where logical decoding was introduced). While at it, fix a nearby
typo. Discussion:
https://www.postgresql.org/message-id/flat/738a590a-2ce5-9394-2bef-7b1caad89b37%402ndquadrant.com
https://git.postgresql.org/pg/commitdiff/fa73b377ee11ced0c051fb42c29a87b5c71b79e3

- Remove remaining GEODEBUG references from geo_ops.c. Commit
a7dc63d904a6044d299aebdf59ad3199b6a9e99d removed most of the GEODEBUG
occurrences, but there were a couple remaining. So remove them too, to get rid
of the macro entirely. Author: Emre Hasegeli Discussion:
https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
https://git.postgresql.org/pg/commitdiff/a082aed0723c737ec65222730ccede5db5251b4d

- Use the built-in float datatypes to implement geometric types. This patch
makes the geometric operators and functions use the exported function of the
float4/float8 datatypes. The main reason of doing so is to check for
underflow and overflow, and to handle NaNs consciously. The float datatypes
consider NaNs values to be equal and greater than all non-NaN values. This
change considers NaNs equal only for equality operators. The placement
operators, contains, overlaps, left/right of etc. continue to return false
when NaNs are involved. We don't need to worry about them being considered
greater than any-NaN because there aren't any basic comparison operators like
less/greater than for the geometric datatypes. The changes may be summarised
as: * Check for underflow, overflow and division by zero * Consider NaN values
to be equal * Return NULL when the distance is NaN for all closest point
operators * Favour not-NaN over NaN where it makes sense The patch also
replaces all occurrences of "double" as "float8". They are the same, but were
used inconsistently in the same file. Author: Emre Hasegeli Reviewed-by:
Kyotaro Horiguchi, Tomas Vondra Discussion:
https://www.postgresql.org/message-id/CAE2gYzxF7-5djV6-cEvqQu-fNsnt%3DEqbOURx7ZDg%2BVv6ZMTWbg%40mail.gmail.com
https://git.postgresql.org/pg/commitdiff/c4c34008854654279ec30067d72fc5d174d2f42f

Noah Misch pushed:

- MSVC: Remove any tmp_check directory before running a TAP test suite.
Back-patch to v11, where commit 90627cf98a8e7d0531789391fd798c9bfcc3bc1a made
the GNU make build system do likewise. Without this, when a typical
PostgresNode-using test failed, subsequent runs bailed out with a "File
exists" error.
https://git.postgresql.org/pg/commitdiff/a53f0edd64d0b11abc4a87681ba85669ae90ce1f

- MSVC: Finish clean.bat tmp_check coverage. Use wildcards, so one can add a
TAP test suite without updating this file. Back-patch to v11, which omitted
multiple new suites.
https://git.postgresql.org/pg/commitdiff/f3efef434fb107dfec8b7e225779479e39a5a360

== Pending Patches ==

Daniel Gustafsson sent in another revision of a patch to support an optional
message in backend cancel/terminate.

Alexander Korotkov sent in two approaches to fix a problem where LWLocks could
prevent heavier-weight locks from ever being acquired.

Michaël Paquier sent in two revisions of a patch to better document locking
behavior around temp namespaces.

Tom Lane sent in a patch to hold off looking up the next hostname in multi-host
libpq connection info until needed.

Etsuro Fujita sent in another revision of a patch to refuse partition-wise join
when whole-row vars are involved.

Andrew Gierth sent in two revisions of a patch to fix quadratic regex
match/split performance.

Michaël Paquier sent in a patch to improve VACUUM and ANALYZE by avoiding early
lock queue.

Masahiko Sawada sent in a patch to add a parallel option to lazy vacuum.

Masahiko Sawada sent in another revision of a patch to implement a copy function
for logical and physical replication slots.

Peter Eisentraut sent in a patch to use a lower lock level for renaming indexes.

Pavel Stěhule sent in a patch to implement schema private functions.

Pavel Stěhule sent in another revision of a patch to implement schema variables.

Fabien COELHO sent in two more revisions of a patch to pgbench to enable storing
select results into variables.

Tom Lane sent in another revision of a patch to change the current libpq
behavior of "randomly overwrite previous errors" to "append to previous errors".

Alexander Korotkov and Liudmila Mantrova traded patches to fix to_timestamp()'s
format checking.

Andrey V. Lepikhov sent in another revision of a patch to implement retail
IndexTuple deletion.

Amit Langote sent in a patch to eliminate execution-time locking of relations in
PlannedStmt.rtable.

Tomáš Vondra sent in another revision of a patch to fix a memory leak when
serializing TRUNCATE in reorderbuffermemory leak when serializing TRUNCATE in
reorderbuffer.

Surafel Temesgen sent in a patch to implement a PERCENT option for FETCH FIRST
clauses.

Tsutomu Yamada sent in two revisions of a patch to fix the help options of
contrib/oid2name and contrib/vacuumlo.

Yugo Nagata sent in a patch to fix a situation where has_table_privilege returns
an error when a table is specified by schema-qualified name and the user doesn't
have privilege for its schema rather than simply returning false.

Andrey V. Lepikhov sent in a patch to fix a problem where the XLogReadRecord()
function forgets to bind the "record" pointer with the beginning of the
readRecordBuf buffer in the case where a WAL record fits completely inside a
page, and instead returns a pointer to an internal xlog page.

Noriyoshi Shinoda sent in a patch to add a work_mem option to the postgres_fdw.

Michaël Paquier sent in another revision of a patch to improve VACUUM and
ANALYZE by avoiding early lock queue.

Mathias Brossard sent in a patch to add a \dP[+] (partitions) command to psql.

Paul Bonaud sent in two revisions of a patch to clarify a part of the pg_upgrade
documentation with respect to when the latest checkpoint location could be wrong
in a replication cluster.

Fabien COELHO sent in a patch to make libpq's parsing of integers stricter.

Amit Khandekar sent in a patch to slot-ify partition tuple conversion, avoiding
a useless form/deform cycle.

Tom Lane sent in a patch to speed up the snprintf implementation we ship.

Emre Hasegeli sent in two more revisions of a patch to fix floating point
handling of -0 for geometric types.

Ashutosh Bapat and Andres Freund traded patches to implement a TupleTableSlot
abstraction.

Peter Eisentraut sent in a patch to update the documentation where it uses the
word "procedure", now that there are actual PROCEDUREs to document. In passing,
changed CREATE OPERATOR and CREATE TRIGGER to use FUNCTION rather than
PROCEDURE, as they actually use functions.

Peter Eisentraut sent in a patch to remove ATTRIBUTE_FIXED_PART_SIZE.

Jonathan Katz sent in two revisions of a patch to fix the REFRESH MATERIALIZED
VIEW ownership error messages.

Noah Misch sent in two approaches to a fix for a problem on Win32 that
manifested itself as "could not reattach to shared memory" on buildfarm member
dory.