Fix some typos, grammar and style in docs and comments
commit : c7a4fc3dd001646d5938687ad59ab84545d5d043
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 24 Feb 2021 16:14:13 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 24 Feb 2021 16:14:13 +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/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 : 0ccebe779dc0ed1c5f37370f2d5bc59779cf9073
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 : ab208421eeb785fc72a3e7fc1122127029165392
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 : 618d139f82d4222df796e989de3c4c4de0359d7b
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 : 09a3b19e38ee09ce1f12cee9b9537ae66d729ead
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 : 8a07e5bd82486b024e58417c09da193c275b13d3
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 : cc7ea0717b128cb23d564b9b7c899eb6164752fc
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 : f4d781dae6b60424304b141165943185b907990b
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