Clarify the usage of max_replication_slots on the subscriber side.
commit : 90c737669fd2ab8e02ef7e8200adbce6fccf5c65
author : Amit Kapila <akapila@postgresql.org>
date : Wed, 3 Mar 2021 11:49:12 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Wed, 3 Mar 2021 11:49:12 +0530 It was not clear in the docs that the max_replication_slots is also used
to track replication origins on the subscriber side.
Author: Paul Martinez
Reviewed-by: Amit Kapila
Backpatch-through: 10 where logical replication was introduced
Discussion: https://postgr.es/m/CACqFVBZgwCN_pHnW6dMNCrOS7tiHCw6Retf_=U2Vvj3aUSeATw@mail.gmail.com M doc/src/sgml/config.sgml
M doc/src/sgml/logical-replication.sgml
Use native path separators to pg_ctl in initdb
commit : 926139dd04bb77ad3c18c9c69544104d15f69672
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 2 Mar 2021 15:39:34 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 2 Mar 2021 15:39:34 -0300 On Windows, CMD.EXE allegedly does not run a command that uses forward slashes,
so let's convert the path to use backslashes instead.
Backpatch to 10.
Author: Nitin Jadhav <nitinjadhavpostgres@gmail.com>
Reviewed-by: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
Discussion: https://postgr.es/m/CAMm1aWaNDuaPYFYMAqDeJrZmPtNvLcJRS++CcZWY8LT6KcoBZw@mail.gmail.com M src/bin/initdb/initdb.c
Doc: further clarify libpq's description of connection string URIs.
commit : 8386f5840ac08a70a649abc80679ad7c2127b7d7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Feb 2021 15:24:01 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Feb 2021 15:24:01 -0500 Break the synopsis into named parts to make it less confusing.
Make more than zero effort at applying SGML markup. Do a bit
of copy-editing of nearby text.
The synopsis revision is by Alvaro Herrera and Paul Förster,
the rest is my fault. Back-patch to v10 where multi-host
connection strings appeared.
Discussion: https://postgr.es/m/6E752D6B-487C-463E-B6E2-C32E7FB007EA@gmail.com M doc/src/sgml/libpq.sgml
Fix some typos, grammar and style in docs and comments
commit : a8f26f6c8882170d1fa7b86f2d83a314ee746e7e
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 24 Feb 2021 16:14:08 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 24 Feb 2021 16:14:08 +0900 The portions fixing the documentation are backpatched where needed.
Author: Justin Pryzby
Discussion: https://postgr.es/m/20210210235557.GQ20012@telsasoft.com
backpatch-through: 9.6 M doc/src/sgml/charset.sgml
M doc/src/sgml/pageinspect.sgml
M doc/src/sgml/protocol.sgml
M doc/src/sgml/ref/create_type.sgml
M doc/src/sgml/ref/drop_index.sgml
M doc/src/sgml/rules.sgml
Reinstate HEAP_XMAX_LOCK_ONLY|HEAP_KEYS_UPDATED as allowed
commit : bf518fefacc74a75d67a492ebee8d7a585989a34
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 23 Feb 2021 17:30:21 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 23 Feb 2021 17:30:21 -0300 Commit 866e24d47db1 added an assert that HEAP_XMAX_LOCK_ONLY and
HEAP_KEYS_UPDATED cannot appear together, on the faulty assumption that
the latter necessarily referred to an update and not a tuple lock; but
that's wrong, because SELECT FOR UPDATE can use precisely that
combination, as evidenced by the amcheck test case added here.
Remove the Assert(), and also patch amcheck's verify_heapam.c to not
complain if the combination is found. Also, out of overabundance of
caution, update (across all branches) README.tuplock to be more explicit
about this.
Author: Julien Rouhaud <rjuju123@gmail.com>
Reviewed-by: Mahendra Singh Thalor <mahi6run@gmail.com>
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>
Discussion: https://postgr.es/m/20210124061758.GA11756@nol M src/backend/access/heap/README.tuplock
Fix another ancient bug in parsing of BRE-mode regular expressions.
commit : b0645097962575eee3546d7a65420f7c78725cec
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 18 Feb 2021 22:38:55 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 18 Feb 2021 22:38:55 -0500 While poking at the regex code, I happened to notice that the bug
squashed in commit afcc8772e had a sibling: next() failed to return
a specific value associated with the '}' token for a "\{m,n\}"
quantifier when parsing in basic RE mode. Again, this could result
in treating the quantifier as non-greedy, which it never should be in
basic mode. For that to happen, the last character before "\}" that
sets "nextvalue" would have to set it to zero, or it'd have to have
accidentally been zero from the start. The failure can be provoked
repeatably with, for example, a bound ending in digit "0".
Like the previous patch, back-patch all the way. M src/backend/regex/regc_lex.c
Fix compiler warning in back branches (9.6, 10).
commit : 26812bcaa664b17843b3dbc8803551d720109b6e
author : Thomas Munro <tmunro@postgresql.org>
date : Tue, 16 Feb 2021 13:10:37 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Tue, 16 Feb 2021 13:10:37 +1300 Back-patch a tiny bit of commit fbb2e9a0 into 9.6 and 10, to silence an
uninitialized variable warning from GCC 10.2. Seen on buildfarm member
handfish, and my own development workflow where I like to use -Werror.
Discussion: https://postgr.es/m/CA%2BhUKGJRcwvK86Uf5t-FrTekZjqHtpv3u%3D3MuBg8Zw8R933Mqg%40mail.gmail.com M src/backend/utils/misc/guc.c
Default to wal_sync_method=fdatasync on FreeBSD.
commit : 800131df74c4b870b6a459bcee0acc0bb89f75ff
author : Thomas Munro <tmunro@postgresql.org>
date : Mon, 15 Feb 2021 15:43:39 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Mon, 15 Feb 2021 15:43:39 +1300 FreeBSD 13 gained O_DSYNC, which would normally cause wal_sync_method to
choose open_datasync as its default value. That may not be a good
choice for all systems, and performs worse than fdatasync in some
scenarios. Let's preserve the existing default behavior for now.
Like commit 576477e73c4, which did the same for Linux, back-patch to all
supported releases.
Discussion: https://postgr.es/m/CA%2BhUKGLsAMXBQrCxCXoW-JsUYmdOL8ALYvaX%3DCrHqWxm-nWbGA%40mail.gmail.com M doc/src/sgml/config.sgml
M src/backend/utils/misc/postgresql.conf.sample
M src/include/port/freebsd.h
Hold interrupts while running dsm_detach() callbacks.
commit : 4b426f77c3cf7fab24115ddb99174d1efa311aee
author : Thomas Munro <tmunro@postgresql.org>
date : Mon, 15 Feb 2021 13:32:58 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Mon, 15 Feb 2021 13:32:58 +1300 While cleaning up after a parallel query or parallel index creation that
created temporary files, we could be interrupted by a statement timeout.
The error handling path would then fail to clean up the files when it
ran dsm_detach() again, because the callback was already popped off the
list. Prevent this hazard by holding interrupts while the cleanup code
runs.
Thanks to Heikki Linnakangas for this suggestion, and also to Kyotaro
Horiguchi, Masahiko Sawada, Justin Pryzby and Tom Lane for discussion of
this and earlier ideas on how to fix the problem.
Back-patch to all supported releases.
Reported-by: Justin Pryzby <pryzby@telsasoft.com>
Discussion: https://postgr.es/m/20191212180506.GR2082@telsasoft.com M src/backend/storage/ipc/dsm.c
pg_attribute_no_sanitize_alignment() macro
commit : 02e7da01a4362ca241e814d5bf9793e849f1c90c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 13 Feb 2021 17:49:08 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 13 Feb 2021 17:49:08 -0500 Modern gcc and clang compilers offer alignment sanitizers, which help to detect
pointer misalignment. However, our codebase already contains x86-specific
crc32 computation code, which uses unalignment access. Thankfully, those
compilers also support the attribute, which disables alignment sanitizers at
the function level. This commit adds pg_attribute_no_sanitize_alignment(),
which wraps this attribute, and applies it to pg_comp_crc32c_sse42() function.
Back-patch of commits 993bdb9f9 and ad2ad698a, to enable doing
alignment testing in all supported branches.
Discussion: https://postgr.es/m/CAPpHfdsne3%3DT%3DfMNU45PtxdhSL_J2PjLTeS8rwKnJzUR4YNd4w%40mail.gmail.com
Discussion: https://postgr.es/m/475514.1612745257%40sss.pgh.pa.us
Author: Alexander Korotkov, revised by Tom Lane
Reviewed-by: Tom Lane M src/include/c.h
M src/port/pg_crc32c_sse42.c
Avoid divide-by-zero in regex_selectivity() with long fixed prefix.
commit : 374f1cefe56c2f2a6f54f3d8ad7f2454b420418f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 12 Feb 2021 16:26:47 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 12 Feb 2021 16:26:47 -0500 Given a regex pattern with a very long fixed prefix (approaching 500
characters), the result of pow(FIXED_CHAR_SEL, fixed_prefix_len) can
underflow to zero. Typically the preceding selectivity calculation
would have underflowed as well, so that we compute 0/0 and get NaN.
In released branches this leads to an assertion failure later on.
That doesn't happen in HEAD, for reasons I've not explored yet,
but it's surely still a bug.
To fix, just skip the division when the pow() result is zero, so
that we'll (most likely) return a zero selectivity estimate. In
the edge cases where "sel" didn't yet underflow, perhaps this
isn't desirable, but I'm not sure that the case is worth spending
a lot of effort on. The results of regex_selectivity_sub() are
barely worth the electrons they're written on anyway :-(
Per report from Alexander Lakhin. Back-patch to all supported versions.
Discussion: https://postgr.es/m/6de0a0c3-ada9-cd0c-3e4e-2fa9964b41e3@gmail.com M src/backend/utils/adt/selfuncs.c