The grammar requires these options to appear the other way 'round.

jotpe@posteo.de

Discussion: https://postgr.es/m/78933bd0-45ce-690e-b832-a328dd1a5567@posteo.de

The point of having separate ResourceOwnerEnlargeFoo and
ResourceOwnerRememberFoo functions is so that resource allocation
can happen in between.  Doing it in some other order is just wrong.

OpenTemporaryFile() did open(), enlarge, remember, which would leak the
open file if the enlarge step ran out of memory.  Because fd.c has its own
layer of resource-remembering, the consequences look like they'd be limited
to an intratransaction FD leak, but it's still not good.

IncrBufferRefCount() did enlarge, remember, incr-refcount, which would blow
up if the incr-refcount step ever failed.  It was safe enough when written,
but since the introduction of PrivateRefCountHash, I think the assumption
that no error could happen there is pretty shaky.

The odds of real problems from either bug are probably small, but still,
back-patch to supported branches.

Thomas Munro and Tom Lane, per a comment from Andres Freund

The lower case spellings are C and C++ standard and are used in most
parts of the PostgreSQL sources.  The upper case spellings are only used
in some files/modules.  So standardize on the standard spellings.

The APIs for ICU, Perl, and Windows define their own TRUE and FALSE, so
those are left as is when using those APIs.

In code comments, we use the lower-case spelling for the C concepts and
keep the upper-case spelling for the SQL concepts.
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>

Masahiko Sawada

Discussion: http://postgr.es/m/CAD21AoDrf5AOpZ-mX-j6O=zFNFfKaTdHkv3o1X2eSs2nBXALug@mail.gmail.com

Per buildfarm member pademelon.

isdigit(), isspace(), etc are likely to give surprising results if passed a
signed char.  We should always cast the argument to unsigned char to avoid
that.  Error in commit 63d6b97f, found by buildfarm member gaur.
Back-patch to 9.3, like that commit.

Previously server reserved WAL for last two checkpoints,
which used too much disk space for small servers.

Bumps PG_CONTROL_VERSION

Author: Simon Riggs <simon@2ndQuadrant.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>

Add docs to explain this for other backup mechanisms

Author: David Steele <david@pgmasters.net>
Reviewed-by: Petr Jelinek <petr.jelinek@2ndQuadrant.com> et al

configure computed PG_VERSION_NUM incorrectly.  (Coulda sworn I tested
that logic back when, but it had an obvious thinko.)

pg_upgrade had not been taught about the new dispensation with just
one part in the major version number.

Both things accidentally failed to fail with 10.0, but with 10.1 we
got the wrong results.

Per buildfarm.

Security: CVE-2017-12172, CVE-2017-15098, CVE-2017-15099

The problem reported as CVE-2017-15098 was already resolved in HEAD by
commit 37a795a6, but let's add the relevant test cases anyway.

Michael Paquier and Tom Lane, per a report from David Rowley.

Security: CVE-2017-15098

By default, $PGUSER has permission to unlink $PGLOG.  If $PGUSER
replaces $PGLOG with a symbolic link, the server will corrupt the
link-targeted file by appending log messages.  Since these scripts open
$PGLOG as root, the attack works regardless of target file ownership.

"make install" does not install these scripts anywhere.  Users having
manually installed them in the past should repeat that process to
acquire this fix.  Most script users have $PGLOG writable to root only,
located in $PGDATA.  Just before updating one of these scripts, such
users should rename $PGLOG to $PGLOG.old.  The script will then recreate
$PGLOG with proper ownership.

Reviewed by Peter Eisentraut.  Reported by Antoine Scemama.

Security: CVE-2017-12172

The update path of an INSERT ... ON CONFLICT DO UPDATE requires SELECT
permission on the columns of the arbiter index, but it failed to check
for that in the case of an arbiter specified by constraint name.

In addition, for a table with row level security enabled, it failed to
check updated rows against the table's SELECT policies when the update
path was taken (regardless of how the arbiter index was specified).

Backpatch to 9.5 where ON CONFLICT DO UPDATE and RLS were introduced.

Security: CVE-2017-15099

Makefile.global assigns this prerequisite to every target named "check",
but similar targets must mention it explicitly.  Affected targets
failed, tested $PATH binaries, or tested a stale temporary installation.
The src/test/modules examples worked properly when called as "make -C
src/test/modules/$FOO check", but "make -j" allowed the test to start
before the temporary installation was in place.  Back-patch to 9.5,
where commit dcae5fac introduced the
shared temp-install.

In the v10 branch, also back-patch the effects of 1ff01b39 and c29c5789
on these files, to reduce future maintenance issues.  (I'd do it further
back, except that the 9.X branches differ anyway due to xlog-to-wal
link tag renaming.)

This restores the ability, essentially lost in commit
ffaa44cb, to use COPY FREEZE under
REPEATABLE READ isolation.  Back-patch to 9.4, like that commit.

Reviewed by Tom Lane.

Discussion: https://postgr.es/m/CA+TgmoahWDm-7fperBxzU9uZ99LPMUmEpSXLTw9TmrOgzwnORw@mail.gmail.com

Author: Bernd Helmle <mailings@oopsware.de>

As usual, the release notes for other branches will be made by cutting
these down, but put them up for community review first.  Note that a
fair percentage of the entries apply only to prior branches because
their issue was already fixed in 10.0.

Reported-by: Tomonari Katsumata <t.katsumata1122@gmail.com>
Author: Michael Paquier <michael.paquier@gmail.com>

Use "bool" for Boolean variables, rather than "int", matching backend
change f505edac.
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>

Remove useless or inconsistently used return values from functions,
matching backend changes 99bf3282 and
791359fe.
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>

NSUnLinkModule() doesn't take a bool as second argument but one of set
of specific constants.  The numeric values are the same in this case,
but clean it up while we're cleaning up bool use elsewhere.
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>

There doesn't seem to be any good reason to do the filling of the
itemidbase[] array separately from the first traversal of the pointers.
It's certainly not a win if there are any line pointers with storage,
and even if there aren't, this change doesn't insert code into the part
of the first loop that will be traversed in that case.  So let's just
merge the two loops.

Yura Sokolov, reviewed by Claudio Freire

Discussion: https://postgr.es/m/e49befcc6f1d7099834c6fdf5c675a60@postgrespro.ru

btree, hash, and bloom indexes all set up their metapages in standard
format (that is, with pd_lower and pd_upper correctly delimiting the
unused area); but they mostly didn't inform the xlog routines of this.
When calling log_newpage[_buffer], this is bad because it loses the
opportunity to compress unused data out of the WAL record.  When
calling XLogRegisterBuffer, it's not such a performance problem because
all of these call sites also use REGBUF_WILL_INIT, preventing an FPI
image from being written.  But it's still a good idea to provide the
flag when relevant, because that aids WAL consistency checking.

This completes the project of getting all the in-core index AMs to
handle their metapage WAL operations similarly.

Amit Kapila, reviewed by Michael Paquier

Discussion: https://postgr.es/m/0d273805-0e9e-ec1a-cb84-d4da400b8f85@lab.ntt.co.jp

The previous commit contained a thinko that made a single-range
summarization request process from there to end of table.  Fix by
setting the correct end range point.  Per buildfarm.

This makes the produced HTML anchors upper case, making it backward
compatible with the previous (9.6) build system.
Reported-by: Thomas Kellerer <spam_eater@gmx.net>

When a publisher table has fewer columns than a subscriber, the update
of a row on the publisher should result in updating of only the columns
in common.  The previous coding mistakenly reset the values of
additional columns on the subscriber to NULL because it failed to skip
updates of columns not found in the attribute map.

Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>

If a process is extending a table concurrently with some BRIN
summarization process, it is possible for the latter to miss pages added
by the former because the number of pages is computed ahead of time.

Fix by determining a fresh relation size after inserting the placeholder
tuple: any process that further extends the table concurrently will
update the placeholder tuple, while previous pages will be processed by
the heap scan.

Reported-by: Tomas Vondra
Reviewed-by: Tom Lane
Author: Álvaro Herrera
Discussion: https://postgr.es/m/083d996a-4a8a-0e13-800a-851dd09ad8cc@2ndquadrant.com
Backpatch-to: 9.5

Minor refactoring that should yield some performance benefit.

Fabien Coelho, reviewed by Aleksandr Parfenov

Discussion: https://postgr.es/m/alpine.DEB.2.20.1709230538130.4999@lancre

Previously, these index types left the pd_lower field set to the default
SizeOfPageHeaderData, which is really a lie because it ought to point past
whatever space is being used for metadata.  The coding accidentally failed
to fail because we never told xlog.c that the metapage is of standard
format --- but that's not very good, because it impedes WAL consistency
checking, and in some cases prevents compression of full-page images.

To fix, ensure that we set pd_lower correctly, not only when creating a
metapage but whenever we write it out (these apparently redundant steps are
needed to cope with pg_upgrade'd indexes that don't yet contain the right
value).  This allows telling xlog.c that the page is of standard format.

The WAL consistency check mask functions are made to mask only if pd_lower
appears valid, which I think is likely unnecessary complication, since
any metapage appearing in a v11 WAL stream should contain valid pd_lower.
But it doesn't cost much to be paranoid.

Amit Langote, reviewed by Michael Paquier and Amit Kapila

Discussion: https://postgr.es/m/0d273805-0e9e-ec1a-cb84-d4da400b8f85@lab.ntt.co.jp

Change message for restarting a server from a directory without a PID
file.  This accounts for the case where a restart happens after an
initdb.  The new message indicates that the start has not completed yet
and might fail.

Author: Jesper Pedersen <jesper.pedersen@redhat.com>

This changes the use of a custom configuration file to enforce the value
of preload_shared_libraries to simply load the library during the tests.
This removes the restriction of running installcheck on the tests, and
simplifies its makefile contrary to what has been introduced in af7211e9.

Author: Michael Paquier <michael.paquier@gmail.com>

In some cases the BRIN code releases lock on an index page, and later
re-acquires lock and tries to check that the tuple it was working on is
still there.  That check was a couple bricks shy of a load.  It didn't
consider that the page might have turned into a "revmap" page.  (The
samepage code path doesn't call brin_getinsertbuffer(), so it isn't
protected by the checks for revmap status there.)  It also didn't check
whether the tuple offset was now off the end of the linepointer array.
Since commit 24992c6d the latter case is pretty common, but at least
in principle it could have occurred before that.  The net result is
that concurrent updates of a BRIN index could fail with errors like
"invalid index offnum" or "inconsistent range map".

Per report from Tomas Vondra.  Back-patch to 9.5, since this code is
substantially the same in all versions containing BRIN.

Discussion: https://postgr.es/m/10d2b9f9-f427-03b8-8ad9-6af4ecacbee9@2ndquadrant.com

This is only used in the pg_rewind tests, so only set it there.  It's
better if other tests run closer to a default configuration.

Author: Michael Paquier <michael.paquier@gmail.com>

The description has gotten a bit confusing over time, so rewrite the
paragraph a bit.
Reported-by: Feike Steenbergen <feikesteenbergen@gmail.com>

For some reason, we have never accounted for either the evaluation cost
or the selectivity of filter conditions attached to Agg and Group nodes
(which, in practice, are always conditions from a HAVING clause).

Applying our regular selectivity logic to post-grouping conditions is a
bit bogus, but it's surely better than taking the selectivity as 1.0.
Perhaps someday the extended-statistics mechanism can be taught to provide
statistics that would help us in getting non-default estimates here.

Per a gripe from Benjamin Coutu.  This is surely a bug fix, but I'm
hesitant to back-patch because of the prospect of destabilizing existing
plan choices.  Given that it took us this long to notice the bug, it's
probably not hurting too many people in the field.

Discussion: https://postgr.es/m/20968.1509486337@sss.pgh.pa.us