pgsql: Raise C requirement to C11

2025-08-26 Thread 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

pgsql: Refactor variable names in remove_self_joins_one_group()

2025-08-26 Thread 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%4

pgsql: Improve RowMark handling during Self-Join Elimination

2025-08-26 Thread 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 stag

pgsql: Further clarify documentation for the initcap function

2025-08-26 Thread 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

pgsql: Refactor variable names in remove_self_joins_one_group()

2025-08-26 Thread 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%4

pgsql: Improve RowMark handling during Self-Join Elimination

2025-08-26 Thread 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 stag

pgsql: Message style improvements

2025-08-26 Thread 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

pgsql: Message style improvements

2025-08-26 Thread 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_

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

2025-08-26 Thread 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 s

pgsql: Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

2025-08-26 Thread 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 s

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

2025-08-26 Thread 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 s

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

2025-08-26 Thread 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 s

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

2025-08-26 Thread 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 s

pgsql: Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

2025-08-26 Thread 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 s

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

2025-08-26 Thread 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 s

pgsql: Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

2025-08-26 Thread 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 s

pgsql: Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

2025-08-26 Thread 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 s

pgsql: Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

2025-08-26 Thread 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 s

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

2025-08-26 Thread 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 s

pgsql: Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

2025-08-26 Thread 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 s

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

2025-08-26 Thread 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 defaul

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

2025-08-26 Thread 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 defaul

pgsql: Do CHECK_FOR_INTERRUPTS inside, not before, scanGetItem.

2025-08-26 Thread 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 s

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

2025-08-26 Thread 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 s

pgsql: oauth: Explicitly depend on -pthread

2025-08-26 Thread 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-throu

pgsql: oauth: Explicitly depend on -pthread

2025-08-26 Thread 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-throu

pgsql: Check for more Unicode functions during upgrade.

2025-08-26 Thread 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 reference

pgsql: Check for more Unicode functions during upgrade.

2025-08-26 Thread 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 reference