== PostgreSQL Weekly News - June 14, 2020 ==

From: David Fetter <david(at)fetter(dot)org>
To: PostgreSQL Announce <pgsql-announce(at)postgresql(dot)org>
Subject: == PostgreSQL Weekly News - June 14, 2020 ==
Date: 2020-06-15 03:33:15
Message-ID: 20200615033315.GA19182@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-announce

== PostgreSQL Weekly News - June 14, 2020 ==

== PostgreSQL Product News ==

pgsodium 1.1.1, an extention which adds libsodium encryption to PostgreSQL, released.
https://github.com/michelp/pgsodium

pgbouncer 1.14.0, a connection pooler and more for PostgreSQL, released.
https://pgbouncer.github.io/2020/06/pgbouncer-1-14-0

== PostgreSQL Jobs for June ==

http://archives.postgresql.org/pgsql-jobs/2020-06/

== PostgreSQL Local ==

FOSS4G 2020, will take place in Calgary, Alberta, Canada August 24-29 2020.
the Call for Papers is currently open at https://2020.foss4g.org/speakers/
https://2020.foss4g.org/

PGDay Ukraine will take place September 5th, 2020 in Lviv at the Bank Hotel.
https://pgday.org.ua/

pgDay Israel 2020 will take place on September 10, 2020 in Tel Aviv.
http://pgday.org.il/

PGDay Austria will take place September 18, 2020 at Schloss Schoenbrunn
(Apothekertrakt) in Vienna.
https://pgday.at/en/

PostgreSQL Conference Europe 2020 will be held on October 20-23, 2020 in Berlin,
Germany. The CfP is open through July 31, 2020 at https://2020.pgconf.eu/callforpapers
https://2020.pgconf.eu/

PG Day Russia will take place in Saint Petersburg on July 9, 2021.
https://pgday.ru/en/2020/

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

- pgindent run prior to branching v13. pgperltidy and reformat-dat-files too,
though those didn't find anything to change.
https://git.postgresql.org/pg/commitdiff/b5d69b7c22ee4c44b8bb99cfa0466ffaf3b5fab9

- Stamp HEAD as 14devel. Let the hacking begin ...
https://git.postgresql.org/pg/commitdiff/d10b19e224c2ead10b59382f695f0c2bd65039fa

- Repair unstable regression test. Commit 0c882e52a tried to force table atest12
to have more-accurate- than-default statistics; but transiently setting
default_statistics_target isn't enough for that, because autovacuum could come
along and overwrite the stats later. This evidently explains some
intermittent buildfarm failures we've seen since then. Repair by disabling
autovac on this table. Thanks to David Rowley for correctly diagnosing the
cause. Discussion:
https://postgr.es/m/CA+hUKG+OUkQSOUTg=qo=S=fWa_tbm99i7rB7mfbHz1SYm4v-jQ@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/05dea2427c2f6ba83f0b11f4e9472db2032dc1c7

- Fix mishandling of NaN counts in numeric_[avg_]combine. When merging two
NumericAggStates, the code missed adding the new state's NaNcount unless its N
was also nonzero; since those counts are independent, this is wrong. This
would only have visible effect if some partial aggregate scans found only NaNs
while earlier ones found only non-NaNs; then we could end up falsely deciding
that there were no NaNs and fail to return a NaN final result as expected.
That's pretty improbable, so it's no surprise this hasn't been reported from
the field. Still, it's a bug. I didn't try to produce a regression test that
would show the bug, but I did notice that these functions weren't being
reached at all in our regression tests, so I improved the tests to at least
exercise them. With these additions, I see pretty complete code coverage on
the aggregation-related functions in numeric.c. Back-patch to 9.6 where this
code was introduced. (I only added the improved test case as far back as v10,
though, since the relevant part of aggregates.sql isn't there at all in 9.6.)
https://git.postgresql.org/pg/commitdiff/77a3be32f7c16538bc4e05edad85560d9f88369b

- Avoid using a cursor in plpgsql's RETURN QUERY statement. plpgsql has always
executed the query given in a RETURN QUERY command by opening it as a cursor
and then fetching a few rows at a time, which it turns around and dumps into
the function's result tuplestore. The point of this was to keep from blowing
out memory with an oversized SPITupleTable result (note that while a
tuplestore can spill tuples to disk, SPITupleTable cannot). However, it's
rather inefficient, both because of extra data copying and because of executor
entry/exit overhead. In recent versions, a new performance problem has
emerged: use of a cursor prevents use of a parallel plan for the executed
query. We can improve matters by skipping use of a cursor and having the
executor push result tuples directly into the function's result tuplestore.
However, a moderate amount of new infrastructure is needed to make that idea
work: * We can use the existing tstoreReceiver.c DestReceiver code to funnel
executor output to the tuplestore, but it has to be extended to support
plpgsql's requirement for possibly applying a tuple conversion map. * SPI
needs to be extended to allow use of a caller-supplied DestReceiver instead of
its usual receiver that puts tuples into a SPITupleTable. Two new API calls
are needed to handle both the RETURN QUERY and RETURN QUERY EXECUTE cases. I
also felt that I didn't want these new API calls to use the legacy method of
specifying query parameter values with "char" null flags (the old ' '/'n'
convention); rather they should accept ParamListInfo objects containing the
parameter type and value info. This required a bit of additional new
infrastructure since we didn't yet have any parse analysis callback that would
interpret $N parameter symbols according to type data supplied in a
ParamListInfo. There seems to be no harm in letting makeParamList install
that callback by default, rather than leaving a new ParamListInfo's
parserSetup hook as NULL. (Indeed, as of HEAD, I couldn't find anyplace that
was using the parserSetup field at all; plpgsql was using parserSetupArg for
its own purposes, but parserSetup seemed to be write-only.) We can actually
get plpgsql out of the business of using legacy null flags altogether, and
using ParamListInfo instead of its ad-hoc PreparedParamsData structure; but
this requires inventing one more SPI API call that can replace
SPI_cursor_open_with_args. That seems worth doing, though.
SPI_execute_with_args and SPI_cursor_open_with_args are now unused anywhere in
the core PG distribution. Perhaps someday we could deprecate/remove them.
But cleaning up the crufty bits of the SPI API is a task for a different
patch. Per bug #16040 from Jeremy Smith. This is unfortunately too invasive
to consider back-patching. Patch by me; thanks to Hamid Akhtar for review.
Discussion: https://postgr.es/m/16040-eaacad11fecfb198@postgresql.org
https://git.postgresql.org/pg/commitdiff/2f48ede080f42b97b594fb14102c82ca1001b80c

- Fix behavior of float aggregates for single Inf or NaN inputs. When there is
just one non-null input value, and it is infinity or NaN, aggregates such as
stddev_pop and covar_pop should produce a NaN result, because the calculation
is not well-defined. They used to do so, but since we adopted Youngs-Cramer
aggregation in commit e954a727f, they produced zero instead. That's an
oversight, so fix it. Add tests exercising these edge cases. Affected
aggregates are var_pop(double precision) stddev_pop(double precision)
var_pop(real) stddev_pop(real) regr_sxx(double precision,double precision)
regr_syy(double precision,double precision) regr_sxy(double precision,double
precision) regr_r2(double precision,double precision) regr_slope(double
precision,double precision) regr_intercept(double precision,double precision)
covar_pop(double precision,double precision) corr(double precision,double
precision) Back-patch to v12 where the behavior change was accidentally
introduced. Report and patch by me; thanks to Dean Rasheed for review.
Discussion: https://postgr.es/m/353062.1591898766@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/03109a53020e4663df3a8d822cdc665a7d712a93

- Sync behavior of var_samp and stddev_samp for single NaN inputs.
var_samp(numeric) and stddev_samp(numeric) disagreed with their float cousins
about what to do for a single non-null input value that is NaN. The float
versions return NULL on the grounds that the calculation is only defined for
more than one non-null input, which seems like the right answer. But the
numeric versions returned NaN, as a result of dealing with edge cases in the
wrong order. Fix that. The patch also gets rid of an insignificant memory
leak in such cases. This inconsistency is of long standing, but on the whole
it seems best not to back-patch the change into stable branches; nobody's
complained and it's such an obscure point that nobody's likely to complain.
(Note that v13 and v12 now contain test cases that will notice if we
accidentally back-patch this behavior change in future.) Report and patch by
me; thanks to Dean Rasheed for review. Discussion:
https://postgr.es/m/353062.1591898766@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/23cbeda50b94c817bed4f7d2127ee09c4e8c8b86

- Fix behavior of exp() and power() for infinity inputs. Previously, these
functions tended to throw underflow errors for negative-infinity exponents.
The correct thing per POSIX is to return 0, so let's do that instead. (Note
that the SQL standard is silent on such issues, as it lacks the concepts of
either Inf or NaN; so our practice is to follow POSIX whenever a corresponding
C-library function exists.) Also, add a bunch of test cases verifying that
exp() and power() actually do follow POSIX for Inf and NaN inputs. While this
patch should guarantee that exp() passes the tests, power() will not unless
the platform's pow(3) is fully POSIX-compliant. I already know that gaur
fails some of the tests, and I am suspicious that the Windows animals will
too; the extent of compliance of other old platforms remains to be seen. We
might choose to drop failing test cases, or to work harder at overriding
pow(3) for these cases, but first let's see just how good or bad the situation
is. Discussion: https://postgr.es/m/582552.1591917752@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/decbe2bfb1051c5ab6c382b19e1d909e34227a22

Noah Misch pushed:

- MSVC: Avoid warning when testing a TAP suite without PROVE_FLAGS. Commit
7be5d8df1f74b78620167d3abf32ee607e728919 surfaced the logic error, which had
no functional implications, by adding "use warnings". The buildfarm always
customizes PROVE_FLAGS, so the warning did not appear there. Back-patch to
9.5 (all supported versions).
https://git.postgresql.org/pg/commitdiff/5a2398b0b2d30315469ee00ca289ea88b03ccfd8

Michaël Paquier pushed:

- Fix crash in WAL sender when starting physical replication. Since database
connections can be used with WAL senders in 9.4, it is possible to use
physical replication. This commit fixes a crash when starting physical
replication with a WAL sender using a database connection, caused by the
refactoring done in 850196b. There have been discussions about forbidding the
use of physical replication in a database connection, but this is left for
later, taking care only of the crash new to 13. While on it, add a test to
check for a failure when attempting logical replication if the WAL sender does
not have a database connection. This part is extracted from a larger patch by
Kyotaro Horiguchi. Reported-by: Vladimir Sitnikov Author: Michael Paquier,
Kyotaro Horiguchi Reviewed-by: Kyotaro Horiguchi, Álvaro Herrera Discussion:
https://postgr.es/m/CAB=Je-GOWMj1PTPkeUhjqQp-4W3=nW-pXe2Hjax6rJFffB5_Aw@mail.gmail.com
Backpatch-through: 13
https://git.postgresql.org/pg/commitdiff/879ad9f90e83b94db14b8be11f1cc1fb38187cc0

- Move frontend-side archive APIs from src/common/ to src/fe_utils/.
fe_archive.c was compiled only for the frontend in src/common/, but as it will
never share anything with the backend, it makes most sense to move this file
to src/fe_utils/. Reported-by: Peter Eisentraut Discussion:
https://postgr.es/m/e9766d71-8655-ac86-bdf6-77e0e7169977@2ndquadrant.com
Backpatch-through: 13
https://git.postgresql.org/pg/commitdiff/a3b2bf1fe7ce7cf88af6af2c100c6ed61c976780

- Fix typos and some format mistakes in comments. Author: Justin Pryzby
Discussion: https://postgr.es/m/20200612023709.GC14879@telsasoft.com
https://git.postgresql.org/pg/commitdiff/aaf8c990502f7bb28c10f6bab1d23fe2f9f0b537

- Add more TAP tests for pg_dump options with range checks. This adds two tests
for --extra-float-digits and --rows-per-insert, similar to what exists for
--compress. Author: Dong Wook Lee Discussion:
https://postgr.es/m/CAAcByaJsgrB-qc-ALb0mALprRGLAdmcBap7SZxO4kCAU-JEHcQ@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/64725728e790b76c97984b1029d9ffe90bcb2ec4

- Create by default sql/ and expected/ for output directory in pg_regress. Using
--outputdir with a custom output repository has never created by default the
sql/ and expected/ paths generated with contents from respectively input/ and
output/ if they don't exist, while the base output directory gets created if
it does not exist. If sql/ and expected/ are not present, pg_regress would
fail with the path missing, requiring test scripts to create those extra paths
by themselves. This commit changes pg_regress so as both get created by
default if they do not exist, removing the need for external test scripts to
do so. This cleans up two code paths in the tree for pg_upgrade tests in MSVC
and environments able to use test.sh. sql/ and expected/ were created as part
of each test script, but this is not needed anymore as pg_regress handles the
work now. Author: Roman Zharkov, Daniel Gustafsson Reviewed-by: Michael
Paquier, Tom Lane Discussion:
https://postgr.es/m/16484-4d89e9cc11241996@postgresql.org
https://git.postgresql.org/pg/commitdiff/e78900afd217fa3eaa77c51e23a94c1466af421c

- Replace superuser check by ACLs for replication origin functions. This patch
removes the hardcoded check for superuser privileges when executing
replication origin functions. Instead, execution is revoked from public,
meaning that those functions can be executed by a superuser and that access to
them can be granted. Author: Martín Marqués Reviewed-by: Kyotaro Horiguchi,
Michael Paquier, Masahiko Sawada Discussion:
https:/postgr.es/m/CAPdiE1xJMZOKQL3dgHMUrPqysZkgwzSMXETfKkHYnBAB7-0VRQ@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/cc072641d41c55c6aa24a331fc1f8029e0a8d799

Thomas Munro pushed:

- Doc: Update example symptom of systemd misconfiguration. In PostgreSQL 10, we
stopped using System V semaphores on Linux systems. Update the example we
give of an error message from a misconfigured system to show what people are
most likely to see these days. Back-patch to 10, where
PREFERRED_SEMAPHORES=UNNAMED_POSIX arrived. Reviewed-by: Tom Lane
<tgl(at)sss(dot)pgh(dot)pa(dot)us> Discussion:
https://postgr.es/m/CA%2BhUKGLmJUSwybaPQv39rB8ABpqJq84im2UjZvyUY4feYhpWMw%40mail.gmail.com
https://git.postgresql.org/pg/commitdiff/d094bf93014b467cc3c129cc0d7d3f0f69968c96

- Fix locking bugs that could corrupt pg_control. The redo routines for
XLOG_CHECKPOINT_{ONLINE,SHUTDOWN} must acquire ControlFileLock before
modifying ControlFile->checkPointCopy, or the checkpointer could write out a
control file with a bad checksum. Likewise, XLogReportParameters() must
acquire ControlFileLock before modifying ControlFile and calling
UpdateControlFile(). Back-patch to all supported releases. Author: Nathan
Bossart <bossartn(at)amazon(dot)com> Author: Fujii Masao
<masao(dot)fujii(at)oss(dot)nttdata(dot)com> Reviewed-by: Fujii Masao
<masao(dot)fujii(at)oss(dot)nttdata(dot)com> Reviewed-by: Michael Paquier
<michael(at)paquier(dot)xyz> Reviewed-by: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Discussion:
https://postgr.es/m/70BF24D6-DC51-443F-B55A-95735803842A%40amazon.com
https://git.postgresql.org/pg/commitdiff/57cb8063089a7d6c54e27adfd5d028cc01f21536

- Improve comments for [Heap]CheckForSerializableConflictOut(). Rewrite the
documentation of these functions, in light of recent bug fix commit 5940ffb2.
Back-patch to 13 where the check-for-conflict-out code was split up into
AM-specific and generic parts, and new documentation was added that now looked
wrong. Reviewed-by: Peter Geoghegan <pg(at)bowt(dot)ie> Discussion:
https://postgr.es/m/db7b729d-0226-d162-a126-8a8ab2dc4443%40jepsen.io
https://git.postgresql.org/pg/commitdiff/7aa4fb592530b74bf05f62c52b736ee3910691b9

Peter Eisentraut pushed:

- Update snowball. Update to snowball tag v2.0.0. Major changes are new
stemmers for Basque, Catalan, and Hindi. Discussion:
https://www.postgresql.org/message-id/flat/a8eeabd6-2be1-43fe-401e-a97594c38478%402ndquadrant.com
https://git.postgresql.org/pg/commitdiff/cbcc8726bb1c3075e58b9907547104271ff5899b

- Update documentation for snowball update. Discussion:
https://www.postgresql.org/message-id/flat/a8eeabd6-2be1-43fe-401e-a97594c38478%402ndquadrant.com
https://git.postgresql.org/pg/commitdiff/c2e71cb355a43d3ea0eaa6433d07f3681f934d54

- Unify drop-by-OID functions. There are a number of Remove${Something}ById()
functions that are essentially identical in structure and only different in
which catalog they are working on. Refactor this to be one generic function.
The information about which oid column, index, etc. to use was already
available in ObjectProperty for most catalogs, in a few cases it was easily
added. Reviewed-by: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> Reviewed-by:
Robert Haas <robertmhaas(at)gmail(dot)com> Discussion:
https://www.postgresql.org/message-id/flat/331d9661-1743-857f-1cbb-d5728bcd62cb%402ndquadrant.com
https://git.postgresql.org/pg/commitdiff/b1d32d3e3230f00b5baba08f75b4f665c7d6dac6

- Spelling adjustments. similar to 0fd2a79a637f9f96b9830524823df0454e962f96
https://git.postgresql.org/pg/commitdiff/350f47786c3444d822d6d27829dd6a5426487150

- Update description of parameter password_encryption. The previous description
string still described the pre-PostgreSQL 10 (pre
eb61136dc75a76caef8460fa939244d8593100f2) behavior of selecting between
encrypted and unencrypted, but it is now choosing between encryption
algorithms.
https://git.postgresql.org/pg/commitdiff/5a4ada71a8f944600c348a6e4f5feb388ba8bd37

- Change default of password_encryption to scram-sha-256. Also, the legacy
values on/true/yes/1 for password_encryption that mapped to md5 are removed.
The only valid values are now scram-sha-256 and md5. Reviewed-by: Jonathan S.
Katz <jkatz(at)postgresql(dot)org> Discussion:
https://www.postgresql.org/message-id/flat/d5b0ad33-7d94-bdd1-caac-43a1c782cab2%402ndquadrant.com
https://git.postgresql.org/pg/commitdiff/c7eab0e97e6cf1d0c136c22269c10ae11ba874c4

- Remove redundant grammar symbols. access_method, database_name, and index_name
are all just name, and they are not used consistently for their alleged
purpose, so remove them. They have been around since ancient times but have
no current reason for existing. Removing them can simplify future grammar
refactoring. Discussion:
https://www.postgresql.org/message-id/flat/163c00a5-f634-ca52-fc7c-0e53deda8735%402ndquadrant.com
https://git.postgresql.org/pg/commitdiff/c2bd1fec32ab5407a3675272af1a06f425cb5161

- Fold AlterForeignTableStmt into AlterTableStmt. All other relation types are
handled by AlterTableStmt, so it's unnecessary to make a different statement
for foreign tables. Discussion:
https://www.postgresql.org/message-id/flat/163c00a5-f634-ca52-fc7c-0e53deda8735%402ndquadrant.com
https://git.postgresql.org/pg/commitdiff/c4325cefba512772efc108baf8ef7182c3833716

- Remove deprecated syntax from CREATE/DROP LANGUAGE. Remove the option to
specify the language name as a single-quoted string. This has been obsolete
since ee8ed85da3b. Removing it allows better grammar refactoring. The syntax
of the CREATE FUNCTION LANGUAGE clause is not changed. Discussion:
https://www.postgresql.org/message-id/flat/163c00a5-f634-ca52-fc7c-0e53deda8735%402ndquadrant.com
https://git.postgresql.org/pg/commitdiff/5333e014ab943b201fe71cfaf409419c204f36be

- Refactor DROP LANGUAGE grammar. Fold it into the generic DropStmt.
Discussion:
https://www.postgresql.org/message-id/flat/163c00a5-f634-ca52-fc7c-0e53deda8735%402ndquadrant.com
https://git.postgresql.org/pg/commitdiff/3fbd4bb6f494dd70cc5075536a754261853de167

- pg_dump: Remove dead code. Remove some code relevant only for dumping from
pre-7.1 servers, support for which had already been removed by
64f3524e2c8deebc02808aa5ebdfa17859473add.
https://git.postgresql.org/pg/commitdiff/d9fa17aa7c34dea66ce64da6fb4c643e75ba452c

- Make more use of RELKIND_HAS_STORAGE(). Make use of RELKIND_HAS_STORAGE()
where appropriate, instead of listing out the relkinds individually. No
behavior change intended. Reviewed-by: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Discussion:
https://www.postgresql.org/message-id/flat/7a22bf51-2480-d999-1794-191ba67ff47c%402ndquadrant.com
https://git.postgresql.org/pg/commitdiff/ffd2582297b86f640b60ba46097b70743f920d35

- Refactor AlterExtensionContentsStmt grammar. Make use of the general object
support already used by COMMENT, DROP, and SECURITY LABEL. Discussion:
https://www.postgresql.org/message-id/flat/163c00a5-f634-ca52-fc7c-0e53deda8735%402ndquadrant.com
https://git.postgresql.org/pg/commitdiff/8f5b5967441f05e56446fa4cdeffd0774c01e553

- Grammar object type refactoring. Unify the grammar of COMMENT, DROP, and
SECURITY LABEL further. They all effectively just take an object address for
later processing, so we can make the grammar more generalized. Some extra
checking about which object types are supported can be done later in the
statement execution. Discussion:
https://www.postgresql.org/message-id/flat/163c00a5-f634-ca52-fc7c-0e53deda8735%402ndquadrant.com
https://git.postgresql.org/pg/commitdiff/a332b366d4fa19ee3578a864993a8dc7abb47177

- Add test coverage for EXTRACT(). The variants for time and timetz had zero
test coverage, the variant for interval only very little. This adds
practically full coverage for those functions. Reviewed-by: Vik Fearing
<vik(at)postgresfriends(dot)org> Reviewed-by: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Discussion:
https://www.postgresql.org/message-id/flat/c3306ac7-fcae-a1b8-1e30-6a379d605bcb%402ndquadrant.com
https://git.postgresql.org/pg/commitdiff/378badc8ebebc8fece7a18001f6b876cc00b12c0

Andres Freund pushed:

- Avoid need for valgrind suppressions for pg_atomic_init_u64 on some platforms.
Previously we used pg_atomic_write_64_impl inside pg_atomic_init_u64. That
works correctly, but on platforms without 64bit single copy atomicity it could
trigger spurious valgrind errors about uninitialized memory, because we use
compare_and_swap for atomic writes on such platforms. I previously suppressed
one instance of this problem (6c878edc1df), but as Tom reports that wasn't
enough. As the atomic variable cannot yet be concurrently accessible during
initialization, it seems better to have pg_atomic_init_64_impl set the value
directly. Change pg_atomic_init_u32_impl for symmetry. Reported-By: Tom Lane
Author: Andres Freund Discussion:
https://postgr.es/m/1714601.1591503815@sss.pgh.pa.us Backpatch: 9.5-
https://git.postgresql.org/pg/commitdiff/47c718792b885c2a06e32cf86f4caca69ce5cda4

Jeff Davis pushed:

- Fix HashAgg regression from choosing too many initial buckets. Diagnosis by
Andres. Reported-by: Pavel Stehule Discussion:
https://postgr.es/m/CAFj8pRDLVakD5Aagt3yZeEQeTeEWaS3YE5h8XC3Q3qJ6TYkc2Q%40mail.gmail.com
Backpatch-through: 13
https://git.postgresql.org/pg/commitdiff/1b2c29469a58cd9086bd86e20c708eb437564a80

- Rework HashAgg GUCs. Eliminate enable_groupingsets_hash_disk, which was
primarily useful for testing grouping sets that use HashAgg and spill.
Instead, hack the table stats to convince the planner to choose hashed
aggregation for grouping sets that will spill to disk. Suggested by Melanie
Plageman. Rename enable_hashagg_disk to hashagg_avoid_disk_plan, and invert
the meaning of on/off. The new name indicates more strongly that it only
affects the planner. Also, the word "avoid" is less definite, which should
avoid surprises when HashAgg still needs to use the disk. Change suggested by
Justin Pryzby, though I chose a different GUC name. Discussion:
https://postgr.es/m/CAAKRu_aisiENMsPM2gC4oUY1hHG3yrCwY-fXUg22C6_MJUwQdA%40mail.gmail.com
Discussion: https://postgr.es/m/20200610021544.GA14879@telsasoft.com
Backpatch-through: 13
https://git.postgresql.org/pg/commitdiff/92c58fd94801dd5c81ee20e26c5bb71ad64552a8

David Rowley pushed:

- Fix invalid function references in a few comments. These appear to have been
forgotten when the functions were renamed in 1fd687a03. Backpatch-through:
13, where the functions were renamed
https://git.postgresql.org/pg/commitdiff/b27c90bbe4a3d607f8fc6703c7183e56e4039acd

- Add missing extern keyword for a couple of numutils functions. In passing,
also remove a few surplus empty lines from pg_ltoa and pg_ulltoa_n in
numutils.c Reported-by: Andrew Gierth Discussion:
https://postgr.es/m/87y2ou3xuh.fsf@news-spur.riddles.org.uk Backpatch-through:
13, where these changes were introduced
https://git.postgresql.org/pg/commitdiff/9a7fccd9eac85726ced3f3794a743eeab447f334

- Have pg_itoa, pg_ltoa and pg_lltoa return the length of the string. Core by no
means makes excessive use of these functions, but quite a large number of
those usages do require the caller to call strlen() on the returned string.
This is quite wasteful since these functions do already have a good idea of
the length of the string, so we might as well just have them return that.
Reviewed-by: Andrew Gierth Discussion:
https://postgr.es/m/CAApHDvrm2A5x2uHYxsqriO2cUaGcFvND%2BksC9e7Tjep0t2RK_A%40mail.gmail.com
https://git.postgresql.org/pg/commitdiff/dad75eb4a8d5835ecc795d7a7978e7702e4d5912

Amit Kapila pushed:

- Fix ReorderBuffer memory overflow check. Commit cec2edfa78 introduced
logical_decoding_work_mem to limit ReorderBuffer memory usage. We spill the
changes once the memory occupied by changes exceeds logical_decoding_work_mem.
There was an assumption in the code that by evicting the largest
(sub)transaction we will come under the memory limit as the selected
transaction will be at least as large as the most recent change (which caused
us to go over the memory limit). However, that is not true because a user can
reduce the logical_decoding_work_mem to a smaller value before the most recent
change. We fix it by allowing to evict the transactions until we reach under
the memory limit. Reported-by: Fujii Masao Author: Amit Kapila Reviewed-by:
Fujii Masao Backpatch-through: 13, where it was introduced Discussion:
https://postgr.es/m/2b7ba291-22e0-a187-d167-9e5309a3458d@oss.nttdata.com
https://git.postgresql.org/pg/commitdiff/c5c000b1038e3037289806f7f29c203f05a2b1e3

- Fix typos. Reported-by: John Naylor Author: John Naylor Backpatch-through: 9.5
Discussion:
https://postgr.es/m/CACPNZCtRuvs6G+EYqejhVJgBq2AKeZdXRVJsbX4syhO9gn5SNQ@mail.gmail.com
https://git.postgresql.org/pg/commitdiff/ad9291f5e6f81ebca978c4438a1c7a448ca5b9ad

Peter Geoghegan pushed:

- Avoid update conflict out serialization anomalies. SSI's
HeapCheckForSerializableConflictOut() test failed to correctly handle
conditions involving a concurrently inserted tuple which is later concurrently
updated by a separate transaction . A SELECT statement that called
HeapCheckForSerializableConflictOut() could end up using the same XID
(updater's XID) for both the original tuple, and the successor tuple, missing
the XID of the xact that created the original tuple entirely. This only
happened when neither tuple from the chain was visible to the transaction's
MVCC snapshot. The observable symptoms of this bug were subtle. A pair of
transactions could commit, with the later transaction failing to observe the
effects of the earlier transaction (because of the confusion created by the
update to the non-visible row). This bug dates all the way back to commit
dafaa3ef, which added SSI. To fix, make sure that we check the xmin of
concurrently inserted tuples that happen to also have been updated
concurrently. Author: Peter Geoghegan Reported-By: Kyle Kingsbury
Reviewed-By: Thomas Munro Discussion:
https://postgr.es/m/db7b729d-0226-d162-a126-8a8ab2dc4443@jepsen.io Backpatch:
All supported versions
https://git.postgresql.org/pg/commitdiff/5940ffb221316ab73e6fdc780dfe9a07d4221ebb

- Silence _bt_check_unique compiler warning. Reported-By: Tom Lane Discussion:
https://postgr.es/m/841649.1592065060@sss.pgh.pa.us
https://git.postgresql.org/pg/commitdiff/d64f1cdf2f4bef1454c74af1028c9ea0c3280322

Bruce Momjian pushed:

- doc: remove xreflabels from commits 75fcdd2ae2 and 85af628da5. xreflabels
prevent references to the chapter numbers of sections id's. It should only be
used in specific cases. Discussion:
https://postgr.es/m/8315c0ca-7758-8823-fcb6-f37f9413e6b6@2ndquadrant.com
Backpatch-through: 9.5
https://git.postgresql.org/pg/commitdiff/0dd1eb3aea636c0b28a18e1290ef108629e5eddd

- doc: document problems with using xreflabel in XML docs. Reported-by: Peter
Eisentraut Discussion:
https://postgr.es/m/8315c0ca-7758-8823-fcb6-f37f9413e6b6@2ndquadrant.com
Backpatch-through: master
https://git.postgresql.org/pg/commitdiff/59fa7eb60364b8e71fe0f515d6ad87c274af839b

== Pending Patches ==

Kyotaro HORIGUCHI sent in another revision of a patch to use shared memory
rather than files for the stats collector.

Thomas Munro sent in a patch to update the docs' example symptom of systemd
misconfiguration.

Melanie Plageman sent in another revision of a patch to implement adaptive
hashjoins.

Thomas Munro sent in two more revisions of a patch to redesign error handling in
buffile.c.

David Fetter sent in a patch to bump the default wal_level to logical.

Pavel Stěhule sent in three revisions of a patch to add a --filter option to
pg_dump which points to a file that lists objects to be included.

Kyotaro HORIGUCHI sent in two revisions of a patch to fix notification
signaling.

Michaël Paquier sent in a patch to move frontend-side archive APIs to
src/fe_utils.

Anastasia Lubennikova sent in two more revisions of a patch to ensure that
pg_upgrade works with nonstandard ACLs.

Dilip Kumar and Amit Kapila traded patches to fix an infelicity between
logical_work_mem and logical streaming of large in-progress transactions.

Peter Eisentraut sent in a patch to enable some symlink tests on Windows.

Andy Fan sent in a patch to Delay the "round to integer" of numIndexTuples to
ensure that the different IndexSelectivity can generate different IndexCosts.

Georgios Kokolatos sent in a patch to include the table AM in psql's in
listTables output.

Kazuki Uehara sent in a patch to fix the remaining function names.

Amit Khandekar sent in a patch to auto-vectorize loops to speed up
large-precision numeric product.

Odin Ugedal sent in two more revisions of a patch to add support for choosing
huge page size.

Aleksey Kondratov and Michaël Paquier traded patches to fix a bug that
manifested as physical replication slot advance is not persistent.

Andrey V. Lepikhov and Kyotaro HORIGUCHI traded patches to add infrastructure
for asynchronous execution and use same in the PostgreSQL FDW.

Dmitry Dolgov sent in another revision of a patch to implement index skip scans.

Li Japin sent in a patch to make it possible to terminate idle sessions
automatically using a new GUC, idle_session_timeout.

Andres Freund sent in another revision of a patch to ensure that spinlocks
contain only atomic operations.

David Rowley sent in two revisions of a patch to speed up usages of pg_*toa()
functions.

Andrey V. Lepikhov sent in another revision of a patch to implement global
snapshots.

Atsushi Torikoshi sent in two more revisions of a patch to expose the counts of
both generic and custom plans in pg_prepared_statements.

Laurenz Albe sent in a patch to force vacuum_defer_cleanup_age=0 during
pg_upgrade.

Julien Rouhaud sent in another revision of a patch to implement collation
versioning.

Nathan Bossart sent in two revisions of a patch to add support for INDEX_CLEANUP
and TRUNCATE to vacuumdb.

Ranier Vilela sent in two revisions of a patch to fix two more shadow variables.

Peter Eisentraut sent in another revision of a patch to remove STATUS_WAITING.

Justin Pryzby sent in two more revisions of a patch to implement CREATE INDEX
CONCURRENTLY for partitioned tables.

David Rowley sent in another revision of a patch to use larger step sizes for
Parallel Seq Scan.

Mark Dilger sent in four more revisions of a patch to add verify_heapam and
pg_amcheck.

Robert Haas sent in a patch to implement flexible options for BASE_BACKUP and
CREATE_REPLICATION_SLOT.

Amit Langote sent in a patch to fix a bug with RETURNING when UPDATE "moves"
tuple.

Jeff Davis and Andres Freund traded patches to refactor hashlookup.

Amit Langote sent in another revision of a patch to overhaul UPDATE's targetlist
processing and how inherited UPDATE/DELETE are handled.

Justin Pryzby sent in another revision of a patch to update some documentation
for 13.

Fujii Masao sent in a WIP patch to implement a simple GetWALAvailability.

David Rowley sent in a patch to document building PostgreSQL extensions on
Windows.

Vigneshwaran C sent in another revision of a patch to implement parallel COPY.

Mark Wong sent in a patch to add some documentation examples for pghandler.

Movead Li sent in another revision of a patch to implement CSN-based snapshots.

Ranier Vilela sent in three revisions of a patch to allow Win32 to rename a file
across volumes.

Andres Freund sent in a patch to reduce the timing overhead of EXPLAIN ANALYZE
using rdtsc.

Josef Šimánek sent in a WIP patch to add a progress report for COPY.

Browse pgsql-announce by date

  From Date Subject
Next Message David Fetter 2020-06-21 19:02:02 == PostgreSQL Weekly News - June 21, 2020 ==
Previous Message Peter Eisentraut 2020-06-11 07:36:48 PgBouncer 1.14.0 released