pgsql: Raise C requirement to C11

[Peter Eisentraut]

Raise C requirement to C11

This changes configure and meson.build to require at least C11,
instead of the previous C99.  The installation documentation is
updated accordingly.

configure.ac previously used AC_PROG_CC_C99 to activate C99.  But
there is no AC_PROG_CC_C11 in Autoconf 2.69, because it's too
old.  (Also, post-2.69, the AC_PROG_CC_Cnn macros were deprecated and
AC_PROG_CC activates the last supported C mode.)  We could update the
required Autoconf version, but that might be a separate project that
no one wants to undertake at the moment.  Instead, we open-code the
test for C11 using some inspiration from later Autoconf versions.  But
instead of writing an elaborate test program, we keep it simple and
just check __STDC_VERSION__, which should be good enough in practice.

In meson.build, we update the existing C99 test to C11, but again we
just check for __STDC_VERSION__.

This also removes the separate option for the conforming preprocessor
on MSVC, added by commit 8fd9bb1d965, since that is activated
automatically in C11 mode.

Note, we don't use the "official" way to set the C standard in Meson
using the c_std project option, because that is impossible to use
correctly (see ).

Reviewed-by: David Rowley 
Discussion: 
https://www.postgresql.org/message-id/flat/01a69441-af54-4822-891b-ca28e05b2...@eisentraut.org

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/f5e0186f865cc188ef6f4b2bc77d0c028f78195e

Modified Files
--
configure  | 204 +++--
configure.ac   |  29 +-
doc/src/sgml/installation.sgml |   7 +-
doc/src/sgml/sources.sgml  |  12 +--
meson.build|  59 
5 files changed, 83 insertions(+), 228 deletions(-)

pgsql: Refactor variable names in remove_self_joins_one_group()

[Alexander Korotkov]

Refactor variable names in remove_self_joins_one_group()

Rename inner and outer to rrel and krel, respectively, to highlight their
connection to r and k indexes.  For the same reason, rename imark and omark
to rmark and kmark.

Discussion: https://postgr.es/m/18c6bd6c-6d2a-419a-b0da-dfedef34b585%40gmail.com
Author: Andrei Lepikhov 
Reviewed-by: Greg Sabino Mullane 
Backpatch-through: 18

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/d713cf9b65ae1e7090a62c83bd78dec867871185

Modified Files
--
src/backend/optimizer/plan/analyzejoins.c | 50 +++
1 file changed, 25 insertions(+), 25 deletions(-)

pgsql: Improve RowMark handling during Self-Join Elimination

[Alexander Korotkov]

Improve RowMark handling during Self-Join Elimination

The Self-Join Elimination SJE feature messes up keeping and removing RowMark's
in remove_self_joins_one_group().  That didn't lead to user-level error,
because the planned RowMark is only used to reference a rtable entry in later
execution stages.  An RTE entry for keeping and removing relations is
identical and refers to the same relation OID.

To reduce confusion and prevent future issues, this commit cleans up the code
and fixes the incorrect behaviour.  Furthermore, it includes sanity checks in
setrefs.c on existing non-null RTE and RelOptInfo entries for each RowMark.

Discussion: https://postgr.es/m/18c6bd6c-6d2a-419a-b0da-dfedef34b585%40gmail.com
Author: Andrei Lepikhov 
Reviewed-by: Greg Sabino Mullane 
Backpatch-through: 18

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/5f6f951f88e53630b3ebe9bde762a9612ca6202f

Modified Files
--
src/backend/optimizer/plan/analyzejoins.c | 9 ++---
src/backend/optimizer/plan/setrefs.c  | 4 
2 files changed, 10 insertions(+), 3 deletions(-)

pgsql: Further clarify documentation for the initcap function

[Alexander Korotkov]

Further clarify documentation for the initcap function

This is a follow-up for commit c2c2c7e225.  It further clarifies the
following in the initcap function documentation:

 * Document that title case is used for digraphs in specific locales,
 * Reference particular ICU function used,
 * Add note about the purpose of the function.

Discussion: 
https://postgr.es/m/804cc10ef95d4d3b298e76b181fd9437%40postgrespro.ru
Author: Oleg Tselebrovskiy 
Co-authored-by: Alexander Korotkov 
Reviewed-by: Jeff Davis 
Reviewed-by: Peter Eisentraut 

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/f8ce9ed220b5edd8ba751706bbcdbcc5b64be66e

Modified Files
--
doc/src/sgml/func/func-string.sgml | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)

pgsql: Refactor variable names in remove_self_joins_one_group()

[Alexander Korotkov]

Refactor variable names in remove_self_joins_one_group()

Rename inner and outer to rrel and krel, respectively, to highlight their
connection to r and k indexes.  For the same reason, rename imark and omark
to rmark and kmark.

Discussion: https://postgr.es/m/18c6bd6c-6d2a-419a-b0da-dfedef34b585%40gmail.com
Author: Andrei Lepikhov 
Reviewed-by: Greg Sabino Mullane 
Backpatch-through: 18

Branch
--
REL_18_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/8202b0e83d0928ce9344c31f90cdd4a1e963b568

Modified Files
--
src/backend/optimizer/plan/analyzejoins.c | 50 +++
1 file changed, 25 insertions(+), 25 deletions(-)

pgsql: Improve RowMark handling during Self-Join Elimination

[Alexander Korotkov]

Improve RowMark handling during Self-Join Elimination

The Self-Join Elimination SJE feature messes up keeping and removing RowMark's
in remove_self_joins_one_group().  That didn't lead to user-level error,
because the planned RowMark is only used to reference a rtable entry in later
execution stages.  An RTE entry for keeping and removing relations is
identical and refers to the same relation OID.

To reduce confusion and prevent future issues, this commit cleans up the code
and fixes the incorrect behaviour.  Furthermore, it includes sanity checks in
setrefs.c on existing non-null RTE and RelOptInfo entries for each RowMark.

Discussion: https://postgr.es/m/18c6bd6c-6d2a-419a-b0da-dfedef34b585%40gmail.com
Author: Andrei Lepikhov 
Reviewed-by: Greg Sabino Mullane 
Backpatch-through: 18

Branch
--
REL_18_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/8951941fb8a4d7f239760d7a4cd8fcaeecde13e2

Modified Files
--
src/backend/optimizer/plan/analyzejoins.c | 9 ++---
src/backend/optimizer/plan/setrefs.c  | 4 
2 files changed, 10 insertions(+), 3 deletions(-)

pgsql: Message style improvements

[Peter Eisentraut]

Message style improvements

Mostly adding some quoting.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/e567e22290544c57293f8e5a913292dacd3bcd1a

Modified Files
--
src/backend/catalog/storage.c |  2 +-
src/backend/storage/aio/method_io_uring.c |  2 +-
src/backend/storage/buffer/bufmgr.c   | 34 +---
src/test/modules/test_aio/t/001_aio.pl| 44 +++
4 files changed, 42 insertions(+), 40 deletions(-)

pgsql: Message style improvements

[Peter Eisentraut]

Message style improvements

Mostly adding some quoting.

Branch
--
REL_18_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/952b5a4a9574d7489c51d509edf1cbfb06e96985

Modified Files
--
src/backend/catalog/storage.c |  2 +-
src/backend/storage/aio/method_io_uring.c |  2 +-
src/backend/storage/buffer/bufmgr.c   | 34 +---
src/test/modules/test_aio/t/001_aio.pl| 44 +++
4 files changed, 42 insertions(+), 40 deletions(-)

pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array.

[Tom Lane]

Put "excludeOnly" GIN scan keys at the end of the scankey array.

Commit 4b754d6c1 introduced the concept of an excludeOnly scan key,
which cannot select matching index entries but can reject
non-matching tuples, for example a tsquery such as '!term'.  There are
poorly-documented assumptions that such scan keys do not appear as the
first scan key.  ginNewScanKey did nothing to ensure that, however,
with the result that certain GIN index searches could go into an
infinite loop while apparently-equivalent queries with the clauses in
a different order were fine.

Fix by teaching ginNewScanKey to place all excludeOnly scan keys
after all not-excludeOnly ones.  So far as we know at present,
it might be sufficient to avoid the case where the very first
scan key is excludeOnly; but I'm not very convinced that there
aren't other dependencies on the ordering.

Bug: #19031
Reported-by: Tim Wood 
Author: Tom Lane 
Discussion: https://postgr.es/m/19031-0638148643d25...@postgresql.org
Backpatch-through: 13

Branch
--
REL_15_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/34249b3b58479e48d4f735289e34a13a8c0e8481

Modified Files
--
contrib/pg_trgm/expected/pg_trgm.out | 46 
contrib/pg_trgm/sql/pg_trgm.sql  |  8 +++
src/backend/access/gin/ginscan.c | 43 +
3 files changed, 97 insertions(+)

pgsql: Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

[Tom Lane]

Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

The CHECK_FOR_INTERRUPTS call in gingetbitmap turns out to be
inadequate to prevent a long uninterruptible loop, because
we now know a case where looping occurs within scanGetItem.
While the next patch will fix the bug that caused that, it
seems foolish to assume that no similar patterns are possible.
Let's do the CFI within scanGetItem's retry loop, instead.
This demonstrably allows canceling out of the loop exhibited
in bug #19031.

Bug: #19031
Reported-by: Tim Wood 
Author: Tom Lane 
Discussion: https://postgr.es/m/19031-0638148643d25...@postgresql.org
Backpatch-through: 13

Branch
--
REL_13_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/b2d71c455f05d9d7f959789fcebdc035189defde

Modified Files
--
src/backend/access/gin/ginget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array.

[Tom Lane]

Put "excludeOnly" GIN scan keys at the end of the scankey array.

Commit 4b754d6c1 introduced the concept of an excludeOnly scan key,
which cannot select matching index entries but can reject
non-matching tuples, for example a tsquery such as '!term'.  There are
poorly-documented assumptions that such scan keys do not appear as the
first scan key.  ginNewScanKey did nothing to ensure that, however,
with the result that certain GIN index searches could go into an
infinite loop while apparently-equivalent queries with the clauses in
a different order were fine.

Fix by teaching ginNewScanKey to place all excludeOnly scan keys
after all not-excludeOnly ones.  So far as we know at present,
it might be sufficient to avoid the case where the very first
scan key is excludeOnly; but I'm not very convinced that there
aren't other dependencies on the ordering.

Bug: #19031
Reported-by: Tim Wood 
Author: Tom Lane 
Discussion: https://postgr.es/m/19031-0638148643d25...@postgresql.org
Backpatch-through: 13

Branch
--
REL_17_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/456c6a05d9900816c94f28b750eda3f13a1049fb

Modified Files
--
contrib/pg_trgm/expected/pg_trgm.out | 46 
contrib/pg_trgm/sql/pg_trgm.sql  |  8 +++
src/backend/access/gin/ginscan.c | 43 +
3 files changed, 97 insertions(+)

pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array.

[Tom Lane]

Put "excludeOnly" GIN scan keys at the end of the scankey array.

Commit 4b754d6c1 introduced the concept of an excludeOnly scan key,
which cannot select matching index entries but can reject
non-matching tuples, for example a tsquery such as '!term'.  There are
poorly-documented assumptions that such scan keys do not appear as the
first scan key.  ginNewScanKey did nothing to ensure that, however,
with the result that certain GIN index searches could go into an
infinite loop while apparently-equivalent queries with the clauses in
a different order were fine.

Fix by teaching ginNewScanKey to place all excludeOnly scan keys
after all not-excludeOnly ones.  So far as we know at present,
it might be sufficient to avoid the case where the very first
scan key is excludeOnly; but I'm not very convinced that there
aren't other dependencies on the ordering.

Bug: #19031
Reported-by: Tim Wood 
Author: Tom Lane 
Discussion: https://postgr.es/m/19031-0638148643d25...@postgresql.org
Backpatch-through: 13

Branch
--
REL_13_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/3e0f5f00b34b5bb08e98511bdb89dd31150abdef

Modified Files
--
contrib/pg_trgm/expected/pg_trgm.out | 46 
contrib/pg_trgm/sql/pg_trgm.sql  |  8 +++
src/backend/access/gin/ginscan.c | 43 +
3 files changed, 97 insertions(+)

pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array.

[Tom Lane]

Put "excludeOnly" GIN scan keys at the end of the scankey array.

Commit 4b754d6c1 introduced the concept of an excludeOnly scan key,
which cannot select matching index entries but can reject
non-matching tuples, for example a tsquery such as '!term'.  There are
poorly-documented assumptions that such scan keys do not appear as the
first scan key.  ginNewScanKey did nothing to ensure that, however,
with the result that certain GIN index searches could go into an
infinite loop while apparently-equivalent queries with the clauses in
a different order were fine.

Fix by teaching ginNewScanKey to place all excludeOnly scan keys
after all not-excludeOnly ones.  So far as we know at present,
it might be sufficient to avoid the case where the very first
scan key is excludeOnly; but I'm not very convinced that there
aren't other dependencies on the ordering.

Bug: #19031
Reported-by: Tim Wood 
Author: Tom Lane 
Discussion: https://postgr.es/m/19031-0638148643d25...@postgresql.org
Backpatch-through: 13

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/327b7324d0715f5e1cdd3765f96a486c7b47e778

Modified Files
--
contrib/pg_trgm/expected/pg_trgm.out | 46 
contrib/pg_trgm/sql/pg_trgm.sql  |  8 +++
src/backend/access/gin/ginscan.c | 43 +
3 files changed, 97 insertions(+)

pgsql: Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

[Tom Lane]

Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

The CHECK_FOR_INTERRUPTS call in gingetbitmap turns out to be
inadequate to prevent a long uninterruptible loop, because
we now know a case where looping occurs within scanGetItem.
While the next patch will fix the bug that caused that, it
seems foolish to assume that no similar patterns are possible.
Let's do the CFI within scanGetItem's retry loop, instead.
This demonstrably allows canceling out of the loop exhibited
in bug #19031.

Bug: #19031
Reported-by: Tim Wood 
Author: Tom Lane 
Discussion: https://postgr.es/m/19031-0638148643d25...@postgresql.org
Backpatch-through: 13

Branch
--
REL_17_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/d17abaea8eda7e628d91550b0c059596c3d8b6e1

Modified Files
--
src/backend/access/gin/ginget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array.

[Tom Lane]

Put "excludeOnly" GIN scan keys at the end of the scankey array.

Commit 4b754d6c1 introduced the concept of an excludeOnly scan key,
which cannot select matching index entries but can reject
non-matching tuples, for example a tsquery such as '!term'.  There are
poorly-documented assumptions that such scan keys do not appear as the
first scan key.  ginNewScanKey did nothing to ensure that, however,
with the result that certain GIN index searches could go into an
infinite loop while apparently-equivalent queries with the clauses in
a different order were fine.

Fix by teaching ginNewScanKey to place all excludeOnly scan keys
after all not-excludeOnly ones.  So far as we know at present,
it might be sufficient to avoid the case where the very first
scan key is excludeOnly; but I'm not very convinced that there
aren't other dependencies on the ordering.

Bug: #19031
Reported-by: Tim Wood 
Author: Tom Lane 
Discussion: https://postgr.es/m/19031-0638148643d25...@postgresql.org
Backpatch-through: 13

Branch
--
REL_18_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/3a7a3eaaf9fe6d4669815de719300df124b869e1

Modified Files
--
contrib/pg_trgm/expected/pg_trgm.out | 46 
contrib/pg_trgm/sql/pg_trgm.sql  |  8 +++
src/backend/access/gin/ginscan.c | 43 +
3 files changed, 97 insertions(+)

pgsql: Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

[Tom Lane]

Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

The CHECK_FOR_INTERRUPTS call in gingetbitmap turns out to be
inadequate to prevent a long uninterruptible loop, because
we now know a case where looping occurs within scanGetItem.
While the next patch will fix the bug that caused that, it
seems foolish to assume that no similar patterns are possible.
Let's do the CFI within scanGetItem's retry loop, instead.
This demonstrably allows canceling out of the loop exhibited
in bug #19031.

Bug: #19031
Reported-by: Tim Wood 
Author: Tom Lane 
Discussion: https://postgr.es/m/19031-0638148643d25...@postgresql.org
Backpatch-through: 13

Branch
--
REL_14_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/a7da746c1180f01475c6123bc1efeaefe508

Modified Files
--
src/backend/access/gin/ginget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

pgsql: Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

[Tom Lane]

Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

The CHECK_FOR_INTERRUPTS call in gingetbitmap turns out to be
inadequate to prevent a long uninterruptible loop, because
we now know a case where looping occurs within scanGetItem.
While the next patch will fix the bug that caused that, it
seems foolish to assume that no similar patterns are possible.
Let's do the CFI within scanGetItem's retry loop, instead.
This demonstrably allows canceling out of the loop exhibited
in bug #19031.

Bug: #19031
Reported-by: Tim Wood 
Author: Tom Lane 
Discussion: https://postgr.es/m/19031-0638148643d25...@postgresql.org
Backpatch-through: 13

Branch
--
REL_16_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/25eadfd0fe7b34f5d3a0d574873a871881bf96f9

Modified Files
--
src/backend/access/gin/ginget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

pgsql: Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

[Tom Lane]

Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

The CHECK_FOR_INTERRUPTS call in gingetbitmap turns out to be
inadequate to prevent a long uninterruptible loop, because
we now know a case where looping occurs within scanGetItem.
While the next patch will fix the bug that caused that, it
seems foolish to assume that no similar patterns are possible.
Let's do the CFI within scanGetItem's retry loop, instead.
This demonstrably allows canceling out of the loop exhibited
in bug #19031.

Bug: #19031
Reported-by: Tim Wood 
Author: Tom Lane 
Discussion: https://postgr.es/m/19031-0638148643d25...@postgresql.org
Backpatch-through: 13

Branch
--
REL_15_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/a9c1b9c1c6063cf99b71bd755f48546ba1709f0e

Modified Files
--
src/backend/access/gin/ginget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array.

[Tom Lane]

Put "excludeOnly" GIN scan keys at the end of the scankey array.

Commit 4b754d6c1 introduced the concept of an excludeOnly scan key,
which cannot select matching index entries but can reject
non-matching tuples, for example a tsquery such as '!term'.  There are
poorly-documented assumptions that such scan keys do not appear as the
first scan key.  ginNewScanKey did nothing to ensure that, however,
with the result that certain GIN index searches could go into an
infinite loop while apparently-equivalent queries with the clauses in
a different order were fine.

Fix by teaching ginNewScanKey to place all excludeOnly scan keys
after all not-excludeOnly ones.  So far as we know at present,
it might be sufficient to avoid the case where the very first
scan key is excludeOnly; but I'm not very convinced that there
aren't other dependencies on the ordering.

Bug: #19031
Reported-by: Tim Wood 
Author: Tom Lane 
Discussion: https://postgr.es/m/19031-0638148643d25...@postgresql.org
Backpatch-through: 13

Branch
--
REL_14_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/4a593043eee9b399ff6c1fc40862f820289786c1

Modified Files
--
contrib/pg_trgm/expected/pg_trgm.out | 46 
contrib/pg_trgm/sql/pg_trgm.sql  |  8 +++
src/backend/access/gin/ginscan.c | 43 +
3 files changed, 97 insertions(+)

pgsql: Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

[Tom Lane]

Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

The CHECK_FOR_INTERRUPTS call in gingetbitmap turns out to be
inadequate to prevent a long uninterruptible loop, because
we now know a case where looping occurs within scanGetItem.
While the next patch will fix the bug that caused that, it
seems foolish to assume that no similar patterns are possible.
Let's do the CFI within scanGetItem's retry loop, instead.
This demonstrably allows canceling out of the loop exhibited
in bug #19031.

Bug: #19031
Reported-by: Tim Wood 
Author: Tom Lane 
Discussion: https://postgr.es/m/19031-0638148643d25...@postgresql.org
Backpatch-through: 13

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/b55068236c5e92e211a6bbf8816933fdac02da80

Modified Files
--
src/backend/access/gin/ginget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

pgsql: Document privileges required for vacuumdb --missing-stats-only.

[Nathan Bossart]

Document privileges required for vacuumdb --missing-stats-only.

When vacuumdb's --missing-stats-only option is used, the catalog
query for retrieving the list of relations to process must read
pg_statistic and pg_statistic_ext_data.  However, those catalogs
can only be read by superusers by default, so --missing-stats-only
is effectively superuser-only.  This is unfortunate, but since the
option is primarily intended for use by administrators after
running pg_upgrade, let's just live with it for v18.  This commit
adds a note about the aforementioned privilege requirements to the
documentation for --missing-stats-only.

We first tried to improve matters by modifying the query to read
the pg_stats and pg_stats_ext system views instead.  While that is
indeed more lenient from a privilege standpoint, it is also
borderline incomprehensible.  pg_stats shows rows for which the
user has the SELECT privilege on the corresponding column, and
pg_stats_ext shows rows for tables the user owns.  Meanwhile,
ANALYZE requires either MAINTAIN on the table or, for non-shared
relations, ownership of the database.  But even if the privilege
discrepancies were tolerable, the performance impact was not.
Ultimately, the modified query was substantially more expensive, so
we abandoned the idea.

For v19, perhaps we could introduce a simple, inexpensive way to
discover which relations are missing statistics, such as a system
function or view with similar privilege requirements to ANALYZE.
Unfortunately, it is far too late for anything like that in v18.

Reviewed-by: Yugo Nagata 
Reviewed-by: Fujii Masao 
Discussion: 
https://postgr.es/m/CAHGQGwHh43suEfss1wvBsk7vqiou%3DUY0zcy8HGyE5hBp%2BHZ7SQ%40mail.gmail.com
Backpatch-through: 18

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/984d7165dde7133dbdddc95e95ff56bbb177f628

Modified Files
--
doc/src/sgml/ref/vacuumdb.sgml | 8 
1 file changed, 8 insertions(+)

pgsql: Document privileges required for vacuumdb --missing-stats-only.

[Nathan Bossart]

Document privileges required for vacuumdb --missing-stats-only.

When vacuumdb's --missing-stats-only option is used, the catalog
query for retrieving the list of relations to process must read
pg_statistic and pg_statistic_ext_data.  However, those catalogs
can only be read by superusers by default, so --missing-stats-only
is effectively superuser-only.  This is unfortunate, but since the
option is primarily intended for use by administrators after
running pg_upgrade, let's just live with it for v18.  This commit
adds a note about the aforementioned privilege requirements to the
documentation for --missing-stats-only.

We first tried to improve matters by modifying the query to read
the pg_stats and pg_stats_ext system views instead.  While that is
indeed more lenient from a privilege standpoint, it is also
borderline incomprehensible.  pg_stats shows rows for which the
user has the SELECT privilege on the corresponding column, and
pg_stats_ext shows rows for tables the user owns.  Meanwhile,
ANALYZE requires either MAINTAIN on the table or, for non-shared
relations, ownership of the database.  But even if the privilege
discrepancies were tolerable, the performance impact was not.
Ultimately, the modified query was substantially more expensive, so
we abandoned the idea.

For v19, perhaps we could introduce a simple, inexpensive way to
discover which relations are missing statistics, such as a system
function or view with similar privilege requirements to ANALYZE.
Unfortunately, it is far too late for anything like that in v18.

Reviewed-by: Yugo Nagata 
Reviewed-by: Fujii Masao 
Discussion: 
https://postgr.es/m/CAHGQGwHh43suEfss1wvBsk7vqiou%3DUY0zcy8HGyE5hBp%2BHZ7SQ%40mail.gmail.com
Backpatch-through: 18

Branch
--
REL_18_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/6b34e2157539c6fbdc62a78d7bb49409f222672b

Modified Files
--
doc/src/sgml/ref/vacuumdb.sgml | 8 
1 file changed, 8 insertions(+)

pgsql: Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

[Tom Lane]

Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

The CHECK_FOR_INTERRUPTS call in gingetbitmap turns out to be
inadequate to prevent a long uninterruptible loop, because
we now know a case where looping occurs within scanGetItem.
While the next patch will fix the bug that caused that, it
seems foolish to assume that no similar patterns are possible.
Let's do the CFI within scanGetItem's retry loop, instead.
This demonstrably allows canceling out of the loop exhibited
in bug #19031.

Bug: #19031
Reported-by: Tim Wood 
Author: Tom Lane 
Discussion: https://postgr.es/m/19031-0638148643d25...@postgresql.org
Backpatch-through: 13

Branch
--
REL_18_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/44c2e5b76c985e9f1d5c88bdaa5460ddf73fa37d

Modified Files
--
src/backend/access/gin/ginget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

pgsql: Put "excludeOnly" GIN scan keys at the end of the scankey array.

[Tom Lane]

Put "excludeOnly" GIN scan keys at the end of the scankey array.

Commit 4b754d6c1 introduced the concept of an excludeOnly scan key,
which cannot select matching index entries but can reject
non-matching tuples, for example a tsquery such as '!term'.  There are
poorly-documented assumptions that such scan keys do not appear as the
first scan key.  ginNewScanKey did nothing to ensure that, however,
with the result that certain GIN index searches could go into an
infinite loop while apparently-equivalent queries with the clauses in
a different order were fine.

Fix by teaching ginNewScanKey to place all excludeOnly scan keys
after all not-excludeOnly ones.  So far as we know at present,
it might be sufficient to avoid the case where the very first
scan key is excludeOnly; but I'm not very convinced that there
aren't other dependencies on the ordering.

Bug: #19031
Reported-by: Tim Wood 
Author: Tom Lane 
Discussion: https://postgr.es/m/19031-0638148643d25...@postgresql.org
Backpatch-through: 13

Branch
--
REL_16_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/d532069c391a2b50432f273052196496b7a61c64

Modified Files
--
contrib/pg_trgm/expected/pg_trgm.out | 46 
contrib/pg_trgm/sql/pg_trgm.sql  |  8 +++
src/backend/access/gin/ginscan.c | 43 +
3 files changed, 97 insertions(+)

pgsql: oauth: Explicitly depend on -pthread

[Jacob Champion]

oauth: Explicitly depend on -pthread

Followup to 4e1e41733 and 52ecd05ae. oauth-utils.c uses
pthread_sigmask(), requiring -pthread on Debian bullseye at minimum.

Reported-by: Christoph Berg 
Tested-by: Christoph Berg 
Discussion: https://postgr.es/m/aK4PZgC0wuwQ5xSK%40msg.df7cb.de
Backpatch-through: 18

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/85b380162cd6c66752d1dd020a2d9700da0903c9

Modified Files
--
meson.build | 1 +
src/interfaces/libpq-oauth/Makefile | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)

pgsql: oauth: Explicitly depend on -pthread

[Jacob Champion]

oauth: Explicitly depend on -pthread

Followup to 4e1e41733 and 52ecd05ae. oauth-utils.c uses
pthread_sigmask(), requiring -pthread on Debian bullseye at minimum.

Reported-by: Christoph Berg 
Tested-by: Christoph Berg 
Discussion: https://postgr.es/m/aK4PZgC0wuwQ5xSK%40msg.df7cb.de
Backpatch-through: 18

Branch
--
REL_18_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/bf37808ef61cbd017179b3d92ad606bf31b14b80

Modified Files
--
meson.build | 1 +
src/interfaces/libpq-oauth/Makefile | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)

pgsql: Check for more Unicode functions during upgrade.

[Jeff Davis]

Check for more Unicode functions during upgrade.

When checking for expression indexes that may be affected by a Unicode
update during upgrade, check for a few more functions. Specifically,
check for documented regexp functions, as well as the new CASEFOLD()
function.

Also, fully-qualify references to pg_catalog.text and
pg_catalog.regtype.

Discussion: 
https://postgr.es/m/399b656a3abb0c9283538a040f72199c0601525c.ca...@j-davis.com
Backpatch-through: 18

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/ef5b87b970dc28adeeb88191fbf66c9d6298b112

Modified Files
--
src/bin/pg_upgrade/check.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)

pgsql: Check for more Unicode functions during upgrade.

[Jeff Davis]

Check for more Unicode functions during upgrade.

When checking for expression indexes that may be affected by a Unicode
update during upgrade, check for a few more functions. Specifically,
check for documented regexp functions, as well as the new CASEFOLD()
function.

Also, fully-qualify references to pg_catalog.text and
pg_catalog.regtype.

Discussion: 
https://postgr.es/m/399b656a3abb0c9283538a040f72199c0601525c.ca...@j-davis.com
Backpatch-through: 18

Branch
--
REL_18_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/08aa8f035cea9465813667a219f9895fade80dc6

Modified Files
--
src/bin/pg_upgrade/check.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)