Stamp 9.5.18.
commit : 683c768cbb7adc18fa0be93e41a090a48b000225
author : Tom Lane <[email protected]>
date : Mon, 17 Jun 2019 17:23:53 -0400
committer: Tom Lane <[email protected]>
date : Mon, 17 Jun 2019 17:23:53 -0400 M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc
Translation updates
commit : 944bf6b4df7d005de130e4d1c3a735788f89e5c3
author : Peter Eisentraut <[email protected]>
date : Mon, 17 Jun 2019 14:46:50 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 17 Jun 2019 14:46:50 +0200 Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: add4d9b126931199d7a1e791afe5b4393c7eaef3 M src/backend/po/es.po
M src/bin/initdb/po/de.po
M src/bin/pg_dump/po/de.po
M src/bin/scripts/po/de.po
Release notes for 10.9, 9.6.14, 9.5.18, 9.4.23.
commit : 235cecd9112e866d6b5d466159aa34bd66d817f2
author : Tom Lane <[email protected]>
date : Sun, 16 Jun 2019 15:39:08 -0400
committer: Tom Lane <[email protected]>
date : Sun, 16 Jun 2019 15:39:08 -0400 (11.4 notes are already done.) M doc/src/sgml/release-9.5.sgml
Prefer timezone name "UTC" over alternative spellings.
commit : 6335f8a999d846e5d60c9f463601b6fe80dfef34
author : Andrew Gierth <[email protected]>
date : Sat, 15 Jun 2019 18:15:23 +0100
committer: Andrew Gierth <[email protected]>
date : Sat, 15 Jun 2019 18:15:23 +0100 tzdb 2019a made "UCT" a link to the "UTC" zone rather than a separate
zone with its own abbreviation. Unfortunately, our code for choosing a
timezone in initdb has an arbitrary preference for names earlier in
the alphabet, and so it would choose the spelling "UCT" over "UTC"
when the system is running on a UTC zone.
Commit 23bd3cec6 was backpatched in order to address this issue, but
that code helps only when /etc/localtime exists as a symlink, and does
nothing to help on systems where /etc/localtime is a copy of a zone
file (as is the standard setup on FreeBSD and probably some other
platforms too) or when /etc/localtime is simply absent (giving UTC as
the default).
Accordingly, add a preference for the spelling "UTC", such that if
multiple zone names have equally good content matches, we prefer that
name before applying the existing arbitrary rules. Also add a slightly
lower preference for "Etc/UTC"; lower because that preserves the
previous behaviour of choosing the shorter name, but letting us still
choose "Etc/UTC" over "Etc/UCT" when both exist but "UTC" does
not (not common, but I've seen it happen).
Backpatch all the way, because the tzdb change that sparked this issue
is in those branches too. M src/bin/initdb/findtimezone.c
Attempt to identify system timezone by reading /etc/localtime symlink.
commit : 77dc741a1727f16ce76dcdc6fd5c23bb8267091f
author : Tom Lane <[email protected]>
date : Fri, 14 Jun 2019 11:25:13 -0400
committer: Tom Lane <[email protected]>
date : Fri, 14 Jun 2019 11:25:13 -0400 On many modern platforms, /etc/localtime is a symlink to a file within the
IANA database. Reading the symlink lets us find out the name of the system
timezone directly, without going through the brute-force search embodied in
scan_available_timezones(). This shortens the runtime of initdb by some
tens of ms, which is helpful for the buildfarm, and it also allows us to
reliably select the same zone name the system was actually configured for,
rather than possibly choosing one of IANA's many zone aliases. (For
example, in a system configured for "Asia/Tokyo", the brute-force search
would not choose that name but its alias "Japan", on the grounds of the
latter string being shorter. More surprisingly, "Navajo" is preferred
to either "America/Denver" or "US/Mountain", as seen in an old complaint
from Josh Berkus.)
If /etc/localtime doesn't exist, or isn't a symlink, or we can't make
sense of its contents, or the contents match a zone we know but that
zone doesn't match the observed behavior of localtime(), fall back to
the brute-force search.
Also, tweak initdb so that it prints the zone name it selected.
In passing, replace the last few references to the "Olson" database in
code comments with "IANA", as that's been our preferred term since
commit b2cbced9e.
Back-patch of commit 23bd3cec6. The original intention was to not
back-patch, since this can result in cosmetic behavioral changes ---
for example, on my own workstation initdb now chooses "America/New_York",
where it used to prefer "US/Eastern" which is equivalent and shorter.
However, our hand has been more or less forced by tzdb update 2019a,
which made the "UCT" zone fully equivalent to "UTC". Our old code
now prefers "UCT" on the grounds of it being alphabetically first,
and that's making nobody happy. Choosing the alias indicated by
/etc/localtime is a more defensible behavior. (Users who don't like
the results can always force the decision by setting the TZ environment
variable before running initdb.)
Patch by me, per a suggestion from Robert Haas; review by Michael Paquier
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected] M src/bin/initdb/findtimezone.c
M src/bin/initdb/initdb.c
M src/interfaces/ecpg/pgtypeslib/dt_common.c
Mark ReplicationSlotCtl as PGDLLIMPORT.
commit : 2c5756ba5416e68356d9aa792c00e2d4f4ca2820
author : Tom Lane <[email protected]>
date : Thu, 13 Jun 2019 10:53:17 -0400
committer: Tom Lane <[email protected]>
date : Thu, 13 Jun 2019 10:53:17 -0400 Also MyReplicationSlot, in branches where it wasn't already.
This was discussed in the thread that resulted in c572599c6, but
for some reason nobody pulled the trigger. Now that we have another
request for the same thing, we should just do it.
Craig Ringer
Discussion: https://postgr.es/m/CAMsr+YFTsq-86MnsNng=mPvjjh5EAbzfMK0ptJPvzyvpFARuRg@mail.gmail.com
Discussion: https://postgr.es/m/[email protected] M src/include/replication/slot.h
postgres_fdw: Account for triggers in non-direct remote UPDATE planning.
commit : eddb79705f652f91ea1984172e5561d0ee05f27a
author : Etsuro Fujita <[email protected]>
date : Thu, 13 Jun 2019 17:59:15 +0900
committer: Etsuro Fujita <[email protected]>
date : Thu, 13 Jun 2019 17:59:15 +0900 Previously, in postgresPlanForeignModify, we planned an UPDATE operation
on a foreign table so that we transmit only columns that were explicitly
targets of the UPDATE, so as to avoid unnecessary data transmission, but
if there were BEFORE ROW UPDATE triggers on the foreign table, those
triggers might change values for non-target columns, in which case we
would miss sending changed values for those columns. Prevent optimizing
away transmitting all columns if there are BEFORE ROW UPDATE triggers on
the foreign table.
This is an oversight in commit 7cbe57c34 which added triggers on foreign
tables, so apply the patch all the way back to 9.4 where that came in.
Author: Shohei Mochizuki
Reviewed-by: Amit Langote
Discussion: https://postgr.es/m/[email protected] M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/sql/postgres_fdw.sql
Doc: improve description of allowed spellings for Boolean input.
commit : 1804185c2dbff2339e0d328ca9fbba1d19ff63df
author : Tom Lane <[email protected]>
date : Wed, 12 Jun 2019 22:54:46 -0400
committer: Tom Lane <[email protected]>
date : Wed, 12 Jun 2019 22:54:46 -0400 datatype.sgml failed to explain that boolin() accepts any unique
prefix of the basic input strings. Indeed it was actively misleading
because it called out a few minimal prefixes without mentioning that
there were more valid inputs.
I also felt that it wasn't doing anybody any favors by conflating
SQL key words, valid Boolean input, and string literals containing
valid Boolean input. Rewrite in hopes of reducing the confusion.
Per bug #15836 from Yuming Wang, as diagnosed by David Johnston.
Back-patch to supported branches.
Discussion: https://postgr.es/m/[email protected] M doc/src/sgml/datatype.sgml
Fix incorrect printing of queries with duplicated join names.
commit : bf612fd3a4d8ff4953f400deccc3c8d1e411e935
author : Tom Lane <[email protected]>
date : Wed, 12 Jun 2019 19:42:39 -0400
committer: Tom Lane <[email protected]>
date : Wed, 12 Jun 2019 19:42:39 -0400 Given a query in which multiple JOIN nodes used the same alias
(which'd necessarily be in different sub-SELECTs), ruleutils.c
would assign the JOIN nodes distinct aliases for clarity ...
but then it forgot to print the modified aliases when dumping
the JOIN nodes themselves. This results in a dump/reload hazard
for views, because the emitted query is flat-out incorrect:
Vars will be printed with table names that have no referent.
This has been wrong for a long time, so back-patch to all supported
branches.
Philip Dubé
Discussion: https://postgr.es/m/CY4PR2101MB080246F2955FF58A6ED1FEAC98140@CY4PR2101MB0802.namprd21.prod.outlook.com M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql
Fix ALTER COLUMN TYPE failure with a partial exclusion constraint.
commit : f7e99de95654b124330b06e0c406d56db5922794
author : Tom Lane <[email protected]>
date : Wed, 12 Jun 2019 12:29:24 -0400
committer: Tom Lane <[email protected]>
date : Wed, 12 Jun 2019 12:29:24 -0400 ATExecAlterColumnType failed to consider the possibility that an index
that needs to be rebuilt might be a child of a constraint that needs to be
rebuilt. We missed this so far because usually a constraint index doesn't
have a direct dependency on its table, just on the constraint object.
But if there's a WHERE clause, then dependency analysis of the WHERE
clause results in direct dependencies on the column(s) mentioned in WHERE.
This led to trying to drop and rebuild both the constraint and its
underlying index.
In v11/HEAD, we successfully drop both the index and the constraint,
and then try to rebuild both, and of course the second rebuild hits a
duplicate-index-name problem. Before v11, it fails with obscure messages
about a missing relation OID, due to trying to drop the index twice.
This is essentially the same kind of problem noted in commit
20bef2c31: the possible dependency linkages are broader than what
ATExecAlterColumnType was designed for. It was probably OK when
written, but it's certainly been broken since the introduction of
partial exclusion constraints. Fix by adding an explicit check
for whether any of the indexes-to-be-rebuilt belong to any of the
constraints-to-be-rebuilt, and ignoring any that do.
In passing, fix a latent bug introduced by commit 8b08f7d48: in
get_constraint_index() we must "continue" not "break" when rejecting
a relation of a wrong relkind. This is harmless today because we don't
expect that code path to be taken anyway; but if there ever were any
relations to be ignored, the existing coding would have an extremely
undesirable dependency on the order of pg_depend entries.
Also adjust a couple of obsolete comments.
Per bug #15835 from Yaroslav Schekin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected] M src/backend/catalog/pg_depend.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Fix handling of COMMENT for domain constraints
commit : 13f4b462dbe87996321c601d46acf2fad39628d0
author : Michael Paquier <[email protected]>
date : Wed, 12 Jun 2019 11:31:20 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 12 Jun 2019 11:31:20 +0900 For a non-superuser, changing a comment on a domain constraint was
leading to a cache lookup failure as the code tried to perform the
ownership lookup on the constraint OID itself, thinking that it was a
type, but this check needs to happen on the type the domain constraint
relies on. As the type a domain constraint relies on can be guessed
directly based on the constraint OID, first fetch its type OID and
perform the ownership on it.
This is broken since 7eca575, which has split the handling of comments
for table constraints and domain constraints, so back-patch down to
9.5.
Reported-by: Clemens Ladisch
Author: Daniel Gustafsson, Michael Paquier
Reviewed-by: Álvaro Herrera
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5 M src/backend/catalog/objectaddress.c
M src/test/regress/input/constraints.source
M src/test/regress/output/constraints.source
Don't access catalogs to validate GUCs when not connected to a DB.
commit : 483b2d7ae173e29515ec1473880fd173208144b0
author : Andres Freund <[email protected]>
date : Mon, 10 Jun 2019 23:20:48 -0700
committer: Andres Freund <[email protected]>
date : Mon, 10 Jun 2019 23:20:48 -0700 Vignesh found this bug in the check function for
default_table_access_method's check hook, but that was just copied
from older GUCs. Investigation by Michael and me then found the bug in
further places.
When not connected to a database (e.g. in a walsender connection), we
cannot perform (most) GUC checks that need database access. Even when
only shared tables are needed, unless they're
nailed (c.f. RelationCacheInitializePhase2()), they cannot be accessed
without pg_class etc. being present.
Fix by extending the existing IsTransactionState() checks to also
check for MyDatabaseOid.
Reported-By: Vignesh C, Michael Paquier, Andres Freund
Author: Vignesh C, Andres Freund
Discussion: https://postgr.es/m/CALDaNm1KXK9gbZfY-p_peRFm_XrBh1OwQO1Kk6Gig0c0fVZ2uw%40mail.gmail.com
Backpatch: 9.4- M src/backend/commands/tablespace.c
M src/backend/utils/cache/ts_cache.c
Fix copy-pasto in freeing memory on error in vacuumlo.
commit : 99b5ff2eaf4c64c6ac8204f622075d7f01ff4cc2
author : Heikki Linnakangas <[email protected]>
date : Fri, 7 Jun 2019 12:44:06 +0300
committer: Heikki Linnakangas <[email protected]>
date : Fri, 7 Jun 2019 12:44:06 +0300 It's harmless to call PQfreemem() with a NULL argument, so the only
consequence was that if allocating 'schema' failed, but allocating 'table'
or 'field' succeeded, we would leak a bit of memory. That's highly
unlikely to happen, so this is just academical, but let's get it right.
Per bug #15838 from Timur Birsh. Backpatch back to 9.5, where the
PQfreemem() calls were introduced.
Discussion: https://www.postgresql.org/message-id/[email protected] M contrib/vacuumlo/vacuumlo.c
Fix documentation of check_option in information_schema.views
commit : 0022aa31ecc83bd9d6eb8a6c9ffc8f5849875342
author : Michael Paquier <[email protected]>
date : Sat, 1 Jun 2019 15:34:17 -0400
committer: Michael Paquier <[email protected]>
date : Sat, 1 Jun 2019 15:34:17 -0400 Support of CHECK OPTION for updatable views has been added in 9.4, but
the documentation of information_schema never got the call even if the
information displayed is correct.
Author: Gilles Darold
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4 M doc/src/sgml/information_schema.sgml
Fix C++ incompatibilities in plpgsql's header files.
commit : da53e4f93fb3a03f6d5a7d4b98135361fae2ade0
author : Tom Lane <[email protected]>
date : Fri, 31 May 2019 12:34:55 -0400
committer: Tom Lane <[email protected]>
date : Fri, 31 May 2019 12:34:55 -0400 Rename some exposed parameters so that they don't conflict with
C++ reserved words.
Back-patch to all supported versions.
George Tarasov
Discussion: https://postgr.es/m/[email protected] M src/pl/plpgsql/src/plpgsql.h
MSVC: Add "use File::Path qw(rmtree)".
commit : d759ddaaf4b983928bfaf171bab859c874531d93
author : Noah Misch <[email protected]>
date : Tue, 28 May 2019 19:28:36 -0700
committer: Noah Misch <[email protected]>
date : Tue, 28 May 2019 19:28:36 -0700 My back-patch of commit 10b72deafea5972edcafb9eb3f97154f32ccd340 added
calls to File::Path::rmtree(), but v10 and older had not been importing
that symbol. Back-patch to v10, 9.6 and 9.5. M src/tools/msvc/vcregress.pl
In the pg_upgrade test suite, don't write to src/test/regress.
commit : 5c0fee0be2f64439149a37bc4bc4f44b1fcdcda8
author : Noah Misch <[email protected]>
date : Tue, 28 May 2019 12:59:00 -0700
committer: Noah Misch <[email protected]>
date : Tue, 28 May 2019 12:59:00 -0700 When this suite runs installcheck, redirect file creations from
src/test/regress to src/bin/pg_upgrade/tmp_check/regress. This closes a
race condition in "make -j check-world". If the pg_upgrade suite wrote
to a given src/test/regress/results file in parallel with the regular
src/test/regress invocation writing it, a test failed spuriously. Even
without parallelism, in "make -k check-world", the suite finishing
second overwrote the other's regression.diffs. This revealed test
"largeobject" assuming @abs_builddir@ is getcwd(), so fix that, too.
Buildfarm client REL_10, released fifty-four days ago, supports saving
regression.diffs from its new location. When an older client reports a
pg_upgradeCheck failure, it will no longer include regression.diffs.
Back-patch to 9.5, where pg_upgrade moved to src/bin.
Reviewed (in earlier versions) by Andrew Dunstan.
Discussion: https://postgr.es/m/[email protected] M src/bin/pg_upgrade/test.sh
M src/test/regress/input/largeobject.source
M src/test/regress/output/largeobject.source
M src/test/regress/output/largeobject_1.source
M src/tools/msvc/vcregress.pl
In the pg_upgrade test suite, remove and recreate "tmp_check".
commit : f3798089d84e965b4570d4e774afe110d805f8e0
author : Noah Misch <[email protected]>
date : Tue, 28 May 2019 12:58:30 -0700
committer: Noah Misch <[email protected]>
date : Tue, 28 May 2019 12:58:30 -0700 This allows "vcregress upgradecheck" to pass twice in immediate
succession, and it's more like how $(prove_check) works. Back-patch to
9.5, where pg_upgrade moved to src/bin.
Discussion: https://postgr.es/m/[email protected] M src/bin/pg_upgrade/test.sh
M src/tools/msvc/vcregress.pl
pg_upgrade: Make test.sh's installcheck use to-be-upgraded version's bindir.
commit : 7ac46b1ae940f85e5a41a5666f8e0a61912a8314
author : Andres Freund <[email protected]>
date : Thu, 23 May 2019 14:46:57 -0700
committer: Andres Freund <[email protected]>
date : Thu, 23 May 2019 14:46:57 -0700 On master (after 700538) the old version's installed psql was used -
even when the old version might not actually be installed / might be
installed into a temporary directory. As commonly the case when just
executing make check for pg_upgrade, as $oldbindir is just the current
version's $bindir.
In the back branches, with --install specified, psql from the new
version's temporary installation was used, without --install (e.g for
NO_TEMP_INSTALL, cf 47b3c26642), the new version's installed psql was
used (which might or might not exist).
Author: Andres Freund
Discussion: https://postgr.es/m/[email protected] M src/bin/pg_upgrade/test.sh
Fix some grammar in documentation of spgist and pgbench
commit : cd703f5e17d50f105e110c99165ec734ae997133
author : Michael Paquier <[email protected]>
date : Mon, 20 May 2019 09:48:50 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 20 May 2019 09:48:50 +0900 Discussion: https://postgr.es/m/[email protected]
Author: Liudmila Mantrova
Reviewed-by: Jonathan Katz, Tom Lane, Michael Paquier
Backpatch-through: 9.4 M doc/src/sgml/ref/pgbench.sgml
M doc/src/sgml/spgist.sgml
Revert "In the pg_upgrade test suite, don't write to src/test/regress."
commit : 2604751c73e59a1dd148361345b643676c9e4110
author : Noah Misch <[email protected]>
date : Sun, 19 May 2019 15:24:42 -0700
committer: Noah Misch <[email protected]>
date : Sun, 19 May 2019 15:24:42 -0700 This reverts commit bd1592e8570282b1650af6b8eede0016496daecd. It had
multiple defects.
Discussion: https://postgr.es/m/[email protected] M src/bin/pg_upgrade/test.sh
M src/test/regress/input/largeobject.source
M src/test/regress/output/largeobject.source
M src/test/regress/output/largeobject_1.source
M src/tools/msvc/vcregress.pl
In the pg_upgrade test suite, don't write to src/test/regress.
commit : e00b5f090fa04656dd1929786720f500741efbac
author : Noah Misch <[email protected]>
date : Sun, 19 May 2019 14:36:44 -0700
committer: Noah Misch <[email protected]>
date : Sun, 19 May 2019 14:36:44 -0700 When this suite runs installcheck, redirect file creations from
src/test/regress to src/bin/pg_upgrade/tmp_check/regress. This closes a
race condition in "make -j check-world". If the pg_upgrade suite wrote
to a given src/test/regress/results file in parallel with the regular
src/test/regress invocation writing it, a test failed spuriously. Even
without parallelism, in "make -k check-world", the suite finishing
second overwrote the other's regression.diffs. This revealed test
"largeobject" assuming @abs_builddir@ is getcwd(), so fix that, too.
Buildfarm client REL_10, released forty-five days ago, supports saving
regression.diffs from its new location. When an older client reports a
pg_upgradeCheck failure, it will no longer include regression.diffs.
Back-patch to 9.5, where pg_upgrade moved to src/bin.
Reviewed by Andrew Dunstan.
Discussion: https://postgr.es/m/[email protected] M src/bin/pg_upgrade/test.sh
M src/test/regress/input/largeobject.source
M src/test/regress/output/largeobject.source
M src/test/regress/output/largeobject_1.source
M src/tools/msvc/vcregress.pl
Doc: Refer to line pointers as item identifiers.
commit : dd01bbf00cbfd58fae6195070c2440f8f2187045
author : Peter Geoghegan <[email protected]>
date : Mon, 13 May 2019 15:38:59 -0700
committer: Peter Geoghegan <[email protected]>
date : Mon, 13 May 2019 15:38:59 -0700 An upcoming HEAD-only patch will standardize the terminology around
ItemIdData variables/line pointers, ending the practice of referring to
them as "item pointers". Make the "Database Page Layout" docs
consistent with the new policy. The term "item identifier" is already
used in the same section, so stick with that.
Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=E4ndQ2--8ew@mail.gmail.com
Backpatch: All supported branches. M doc/src/sgml/storage.sgml
Fix misuse of an integer as a bool.
commit : 0ec3d2ab250ef696f5e32d4ff7779849bfb0770d
author : Tom Lane <[email protected]>
date : Mon, 13 May 2019 10:53:19 -0400
committer: Tom Lane <[email protected]>
date : Mon, 13 May 2019 10:53:19 -0400 pgtls_read_pending is declared to return bool, but what the underlying
SSL_pending function returns is a count of available bytes.
This is actually somewhat harmless if we're using C99 bools, but in
the back branches it's a live bug: if the available-bytes count happened
to be a multiple of 256, it would get converted to a zero char value.
On machines where char is signed, counts of 128 and up could misbehave
as well. The net effect is that when using SSL, libpq might block
waiting for data even though some has already been received.
Broken by careless refactoring in commit 4e86f1b16, so back-patch
to 9.5 where that came in.
Per bug #15802 from David Binderman.
Discussion: https://postgr.es/m/[email protected] M src/interfaces/libpq/fe-misc.c
M src/interfaces/libpq/fe-secure-openssl.c
Fix misoptimization of "{1,1}" quantifiers in regular expressions.
commit : d6de52636827ab64f537eb78657db125b082bb65
author : Tom Lane <[email protected]>
date : Sun, 12 May 2019 18:53:13 -0400
committer: Tom Lane <[email protected]>
date : Sun, 12 May 2019 18:53:13 -0400 A bounded quantifier with m = n = 1 might be thought a no-op. But
according to our documentation (which traces back to Henry Spencer's
original man page) it still imposes greediness, or non-greediness in the
case of the non-greedy variant "{1,1}?", on whatever it's attached to.
This turns out not to work though, because parseqatom() optimizes away
the m = n = 1 case without regard for whether it's supposed to change
the greediness of the argument RE.
We can fix this by just not applying the optimization when the greediness
needs to change; the subsequent general cases handle it fine.
The three cases in which we can still apply the optimization are
(a) no quantifier, or quantifier does not impose a preference;
(b) atom has no greediness property, implying it cannot match a
variable amount of text anyway; or
(c) quantifier's greediness is same as atom's.
Note that in most cases where one of these applies, we'd have exited
earlier in the "not a messy case" fast path. I think it's now only
possible to get to the optimization when the atom involves capturing
parentheses or a non-top-level backref.
Back-patch to all supported branches. I'd ordinarily be hesitant to
put a subtle behavioral change into back branches, but in this case
it's very hard to see a reason why somebody would write "{1,1}?" unless
they're trying to get the documented change-of-greediness behavior.
Discussion: https://postgr.es/m/[email protected] M src/backend/regex/regcomp.c
M src/test/regress/expected/regex.out
M src/test/regress/sql/regex.sql
Fail pgwin32_message_to_UTF16() for SQL_ASCII messages.
commit : 9dc65bcf9dece8aa92f554db51112645c9751c9e
author : Noah Misch <[email protected]>
date : Sun, 12 May 2019 10:33:05 -0700
committer: Noah Misch <[email protected]>
date : Sun, 12 May 2019 10:33:05 -0700 The function had been interpreting SQL_ASCII messages as UTF8, throwing
an error when they were invalid UTF8. The new behavior is consistent
with pg_do_encoding_conversion(). This affects LOG_DESTINATION_STDERR
and LOG_DESTINATION_EVENTLOG, which will send untranslated bytes to
write() and ReportEventA(). On buildfarm member bowerbird, enabling
log_connections caused an error whenever the role name was not valid
UTF8. Back-patch to 9.4 (all supported versions).
Discussion: https://postgr.es/m/[email protected] M src/backend/utils/mb/mbutils.c
Rearrange pgstat_bestart() to avoid failures within its critical section.
commit : 899f943ca43ad2752e36a44c6ed9dd19cff02f69
author : Tom Lane <[email protected]>
date : Sat, 11 May 2019 21:27:13 -0400
committer: Tom Lane <[email protected]>
date : Sat, 11 May 2019 21:27:13 -0400 We long ago decided to design the shared PgBackendStatus data structure to
minimize the cost of writing status updates, which means that writers just
have to increment the st_changecount field twice. That isn't hooked into
any sort of resource management mechanism, which means that if something
were to throw error between the two increments, the st_changecount field
would be left odd indefinitely. That would cause readers to lock up.
Now, since it's also a bad idea to leave the field odd for longer than
absolutely necessary (because readers will spin while we have it set),
the expectation was that we'd treat these segments like spinlock critical
sections, with only short, more or less straight-line, code in them.
That was fine as originally designed, but commit 9029f4b37 broke it
by inserting a significant amount of non-straight-line code into
pgstat_bestart(), code that is very capable of throwing errors, not to
mention taking a significant amount of time during which readers will spin.
We have a report from Neeraj Kumar of readers actually locking up, which
I suspect was due to an encoding conversion error in X509_NAME_to_cstring,
though conceivably it was just a garden-variety OOM failure.
Subsequent commits have loaded even more dubious code into pgstat_bestart's
critical section (and commit fc70a4b0d deserves some kind of booby prize
for managing to miss the critical section entirely, although the negative
consequences seem minimal given that the PgBackendStatus entry should be
seen by readers as inactive at that point).
The right way to fix this mess seems to be to compute all these values
into a local copy of the process' PgBackendStatus struct, and then just
copy the data back within the critical section proper. This plan can't
be implemented completely cleanly because of the struct's heavy reliance
on out-of-line strings, which we must initialize separately within the
critical section. But still, the critical section is far smaller and
safer than it was before.
In hopes of forestalling future errors of the same ilk, rename the
macros for st_changecount management to make it more apparent that
the writer-side macros create a critical section. And to prevent
the worst consequences if we nonetheless manage to mess it up anyway,
adjust those macros so that they really are a critical section, ie
they now bump CritSectionCount. That doesn't add much overhead, and
it guarantees that if we do somehow throw an error while the counter
is odd, it will lead to PANIC and a database restart to reset shared
memory.
Back-patch to 9.5 where the problem was introduced.
In HEAD, also fix an oversight in commit b0b39f72b: it failed to teach
pgstat_read_current_status to copy st_gssstatus data from shared memory to
local memory. Hence, subsequent use of that data within the transaction
would potentially see changing data that it shouldn't see.
Discussion: https://postgr.es/m/CAPR3Wj5Z17=+eeyrn_ZDG3NQGYgMEOY6JV6Y-WRRhGgwc16U3Q@mail.gmail.com M src/backend/postmaster/pgstat.c
M src/include/pgstat.h
Fix error reporting in reindexdb
commit : e17fba8d8f13a52b544478481c9505e2efe99dc2
author : Michael Paquier <[email protected]>
date : Sat, 11 May 2019 13:01:24 +0900
committer: Michael Paquier <[email protected]>
date : Sat, 11 May 2019 13:01:24 +0900 When failing to reindex a table or an index, reindexdb would generate an
extra error message related to a database failure, which is misleading.
Backpatch all the way down, as this has been introduced by 85e9a5a0.
Discussion: https://postgr.es/m/CAOBaU_Yo61RwNO3cW6WVYWwH7EYMPuexhKqufb2nFGOdunbcHw@mail.gmail.com
Author: Julien Rouhaud
Reviewed-by: Daniel Gustafsson, Álvaro Herrera, Tom Lane, Michael
Paquier
Backpatch-through: 9.4 M src/bin/scripts/reindexdb.c
Cope with EINVAL and EIDRM shmat() failures in PGSharedMemoryAttach.
commit : 91a05390c33c74c8a6bbc7f89d77fe3a8ac5098f
author : Tom Lane <[email protected]>
date : Fri, 10 May 2019 14:56:41 -0400
committer: Tom Lane <[email protected]>
date : Fri, 10 May 2019 14:56:41 -0400 There's a very old race condition in our code to see whether a pre-existing
shared memory segment is still in use by a conflicting postmaster: it's
possible for the other postmaster to remove the segment in between our
shmctl() and shmat() calls. It's a narrow window, and there's no risk
unless both postmasters are using the same port number, but that's possible
during parallelized "make check" tests. (Note that while the TAP tests
take some pains to choose a randomized port number, pg_regress doesn't.)
If it does happen, we treated that as an unexpected case and errored out.
To fix, allow EINVAL to be treated as segment-not-present, and the same
for EIDRM on Linux. AFAICS, the considerations here are basically
identical to the checks for acceptable shmctl() failures, so I documented
and coded it that way.
While at it, adjust PGSharedMemoryAttach's API to remove its undocumented
dependency on UsedShmemSegAddr in favor of passing the attach address
explicitly. This makes it easier to be sure we're using a null shmaddr
when probing for segment conflicts (thus avoiding questions about what
EINVAL means). I don't think there was a bug there, but it required
fragile assumptions about the state of UsedShmemSegAddr during
PGSharedMemoryIsInUse.
Commit c09850992 may have made this failure more probable by applying
the conflicting-segment tests more often. Hence, back-patch to all
supported branches, as that was.
Discussion: https://postgr.es/m/[email protected] M src/backend/port/sysv_shmem.c
Fix error status of vacuumdb when multiple jobs are used
commit : a475b1e77e13ce282603e4133c7cbcbd537d508c
author : Michael Paquier <[email protected]>
date : Thu, 9 May 2019 10:30:08 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 9 May 2019 10:30:08 +0900 When running a batch of VACUUM or ANALYZE commands on a given database,
there were cases where it is possible to have vacuumdb not report an
error where it actually should, leading to incorrect status results.
Author: Julien Rouhaud
Reviewed-by: Amit Kapila, Michael Paquier
Discussion: https://postgr.es/m/CAOBaU_ZuTwz7CtqLYJ1Ouuh272bTQPLN8b1bAPk0bCBm4PDMTQ@mail.gmail.com
Backpatch-through: 9.5 M src/bin/scripts/vacuumdb.c
Fix documentation for the privileges required for replication functions.
commit : 2be2fee248396bbfdeced55f74fd23148e2745af
author : Fujii Masao <[email protected]>
date : Thu, 9 May 2019 01:35:13 +0900
committer: Fujii Masao <[email protected]>
date : Thu, 9 May 2019 01:35:13 +0900 Previously it's documented that use of replication functions is
restricted to superusers. This is true for the functions which
use replication origin, but not for pg_logicl_emit_message() and
functions which use replication slot. For example, not only
superusers but also users with REPLICATION privilege is allowed
to use the functions for replication slot. This commit fixes
the documentation for the privileges required for those replication
functions.
Back-patch to 9.4 (all supported versions).
Author: Matsumura Ryo
Discussion: https://postgr.es/m/03040DFF97E6E54E88D3BFEE5F5480F74ABA6E16@G01JPEXMBYT04 M doc/src/sgml/func.sgml
Remove leftover reference to old "flat file" mechanism in a comment.
commit : f40fb143eddb4838c7309881ff929a65c28dd8d0
author : Heikki Linnakangas <[email protected]>
date : Wed, 8 May 2019 09:32:34 +0300
committer: Heikki Linnakangas <[email protected]>
date : Wed, 8 May 2019 09:32:34 +0300 The flat file mechanism was removed in PostgreSQL 9.0. M src/backend/access/transam/xact.c
Remove some code related to 7.3 and older servers from tools of src/bin/
commit : 6de005121c487152bdfa01a7c1a920ad665a4bd1
author : Michael Paquier <[email protected]>
date : Tue, 7 May 2019 14:20:19 +0900
committer: Michael Paquier <[email protected]>
date : Tue, 7 May 2019 14:20:19 +0900 This code was broken as of 582edc3, and is most likely not used anymore.
Note that pg_dump supports servers down to 8.0, and psql has code to
support servers down to 7.4.
Author: Julien Rouhaud
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/CAOBaU_Y5y=zo3+2gf+2NJC1pvMYPcbRXoQaPXx=U7+C8Qh4CzQ@mail.gmail.com M src/bin/scripts/common.c