pgsql: Fix race condition in TAP test 007_pre_auth
Fix race condition in TAP test 007_pre_auth The authentication test added in c76db55c9085 expects a backend to start and wait at the injection point "init-pre-auth". A query is used to retrieve the PID of the backend waiting at authentication, but its WHERE clause was too soft, checking only for a backend in a "starting" state. As proved by the CI, this WHERE clause is not enough. There is a small window between the moment when the backend is reported as "starting" in its backend entry and the moment when it waits in its injection point, and it was possible for the test to return the PID of a backend process not yet waiting in the injection point, causing spurious failures. This issue is fixed by tweaking the query retrieving the PID of the backend waiting before authentication so as we check for "init-pre-auth" in its wait_event. An extra check based on the backend_type is added, based on a suggestion by Jacob, to be more cautious. Error spotted by the CI on Windows, but it could happen anywhere, as long as the authentication path is slow enough compared to the TAP test. Reported-by: Andres Freund Author: Jacob Champion Co-authored-by: Michael Paquier Discussion: https://postgr.es/m/soexrl7oeyku24bj3czupxmv27ow35u6edymp5y3oyoysbe2kb@r3tgoos2xp2x Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e2080261cc8c1a962708843dc4c806e19fb2c44e Modified Files -- src/test/authentication/t/007_pre_auth.pl | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-)
pgsql: vacuumdb: Add option for analyzing only relations missing stats.
vacuumdb: Add option for analyzing only relations missing stats. This commit adds a new --missing-only option that can be used in conjunction with --analyze-only and --analyze-in-stages. When this option is specified, vacuumdb will generate ANALYZE commands for a relation if it is missing any statistics it should ordinarily have. For example, if a table has statistics for one column but not another, we will analyze the whole table. A similar principle applies to extended statistics, expression indexes, and table inheritance. Co-authored-by: Corey Huinker Reviewed-by: TODO Discussion: https://postgr.es/m/Z5O1bpcwDrMgyrYy%40nathan Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5f8eb25706b62923c53172e453c8a4dedd877a3d Author: Nathan Bossart Modified Files -- doc/src/sgml/ref/vacuumdb.sgml | 16 ++ src/bin/scripts/t/102_vacuumdb_stages.pl | 60 + src/bin/scripts/vacuumdb.c | 92 src/test/perl/PostgreSQL/Test/Cluster.pm | 27 ++ 4 files changed, 195 insertions(+)
pgsql: Doc: correct aggressive vacuum threshold for multixact members s
Doc: correct aggressive vacuum threshold for multixact members storage The threshold is two billion members, which was interpreted as 2GB in the documentation. Fix to reflect that each member takes up five bytes, which translates to about 10GB. This is not exact, because of page boundaries. While at it, mention the maximum size 20GB. This has been wrong since commit c552e171d16e, so backpatch to version 14. Author: Alex Friedman Reviewed-by: Sami Imseih Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/cacbfw60uok6fcc02ksyt3ofu9dnuq5royxdw2afisin_p1l...@mail.gmail.com Backpatch-through: 14 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/98aa99b6d68293b500ad3a1042dfa22dd2e96918 Modified Files -- doc/src/sgml/maintenance.sgml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
pgsql: Doc: correct aggressive vacuum threshold for multixact members s
Doc: correct aggressive vacuum threshold for multixact members storage The threshold is two billion members, which was interpreted as 2GB in the documentation. Fix to reflect that each member takes up five bytes, which translates to about 10GB. This is not exact, because of page boundaries. While at it, mention the maximum size 20GB. This has been wrong since commit c552e171d16e, so backpatch to version 14. Author: Alex Friedman Reviewed-by: Sami Imseih Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/cacbfw60uok6fcc02ksyt3ofu9dnuq5royxdw2afisin_p1l...@mail.gmail.com Backpatch-through: 14 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5c8dcf9483349f39ee8da965c3acd3a61cf242fe Modified Files -- doc/src/sgml/maintenance.sgml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
pgsql: Doc: correct aggressive vacuum threshold for multixact members s
Doc: correct aggressive vacuum threshold for multixact members storage The threshold is two billion members, which was interpreted as 2GB in the documentation. Fix to reflect that each member takes up five bytes, which translates to about 10GB. This is not exact, because of page boundaries. While at it, mention the maximum size 20GB. This has been wrong since commit c552e171d16e, so backpatch to version 14. Author: Alex Friedman Reviewed-by: Sami Imseih Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/cacbfw60uok6fcc02ksyt3ofu9dnuq5royxdw2afisin_p1l...@mail.gmail.com Backpatch-through: 14 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bc6a81ac3a8346c9f3cb5fc6f714977127aa2f31 Modified Files -- doc/src/sgml/maintenance.sgml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
pgsql: Doc: correct aggressive vacuum threshold for multixact members s
Doc: correct aggressive vacuum threshold for multixact members storage The threshold is two billion members, which was interpreted as 2GB in the documentation. Fix to reflect that each member takes up five bytes, which translates to about 10GB. This is not exact, because of page boundaries. While at it, mention the maximum size 20GB. This has been wrong since commit c552e171d16e, so backpatch to version 14. Author: Alex Friedman Reviewed-by: Sami Imseih Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/cacbfw60uok6fcc02ksyt3ofu9dnuq5royxdw2afisin_p1l...@mail.gmail.com Backpatch-through: 14 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fcabc3adf889ebf2c2d8d1c084989f5fd95aac2f Modified Files -- doc/src/sgml/maintenance.sgml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
pgsql: Revert "vacuumdb: Add option for analyzing only relations missin
Revert "vacuumdb: Add option for analyzing only relations missing stats." This reverts commit 5f8eb25706b62923c53172e453c8a4dedd877a3d, which in my branch by mistake. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/19e57f4f78e4354d9a21c284868373d28bb0d368 Modified Files -- doc/src/sgml/ref/vacuumdb.sgml | 16 -- src/bin/scripts/t/102_vacuumdb_stages.pl | 60 - src/bin/scripts/vacuumdb.c | 92 src/test/perl/PostgreSQL/Test/Cluster.pm | 27 -- 4 files changed, 195 deletions(-)
pgsql: reindexdb: move PQfinish() calls to the right place
reindexdb: move PQfinish() calls to the right place get_parallel_object_list() has no business closing a connection it did not create. Make things more sensible by closing the connection at the level where it is created, in reindex_one_database(). Extracted from a larger patch by the same author. However, the patch as submitted not only was not described as containing this change, but in addition it contained a fatal flaw whereby reindexdb would crash and fail across all of its TAP test, which is why I list myself as co-author. Author: Ranier Vilela Author: Álvaro Herrera Discussion: https://postgr.es/m/CAEudQArfqr0-s0VVPSEh=0kgOgBJvFNdGW=xsl5rbcr0wdm...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/24503fa95cd8cd57a8d695a910056a1cfcbacefc Modified Files -- src/bin/scripts/reindexdb.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-)
pgsql: Avoid invalidating all RelationSyncCache entries on publication
Avoid invalidating all RelationSyncCache entries on publication change. On change of publication via ALTER PUBLICATION ... SET/ADD/DROP commands, we were invalidating all the relations present in relation sync cache maintained by pgoutput. We need to invalidate only the relation entries that are changed as part of publication DDL. We have ensured that the publication DDL execution generated the invalidations required to invalidate impacted relation sync entries in RelationSyncCache. This improves the performance by avoiding building the cache entries for the cases where a publication has many tables but only one of them is dropped. Author: Shlok Kyal Author: Hayato Kuroda Reviewed-by: Hou Zhijie Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/oscpr01mb14966c09aa201effa706576a7f5...@oscpr01mb14966.jpnprd01.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/588acf6d0ec15d9384c2f712585c0f56936d7bac Modified Files -- src/backend/replication/pgoutput/pgoutput.c | 22 -- 1 file changed, 8 insertions(+), 14 deletions(-)
pgsql: valgrind: Adjust suppressions to handle glibc changes
valgrind: Adjust suppressions to handle glibc changes In newer glibc versions two additional functions appear between send() and socketcall.send(msg): fun:__internal_syscall_cancel fun:__syscall_cancel Due to that our existing suppression do not work anymore. Use '...', like aleady used in other suppressions, to make valgrind ignore these interstitial frames. The problematic suppressions are only in < 15, as they aren't needed after 5891c7a8ed8. Discussion: https://postgr.es/m/d7pyc6wbo2rqhfk24lsgz37766n75vty4jxy5dnppny7ezd4qc@56juadvntebw Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fb9023533de4fb36d4fbed3b204a59b0cffba853 Modified Files -- src/tools/valgrind.supp | 2 ++ 1 file changed, 2 insertions(+)
pgsql: Remove extraneous commas in json{b}_strip_nulls documentation
Remove extraneous commas in json{b}_strip_nulls documentation
Oversight in commit 4603903d294.
Author: Ian Lawrence Barwick
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/0e76f253f4f0bf3d8a85e88dbea62a09be1f3ff8
Modified Files
--
doc/src/sgml/func.sgml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Further fix for json_strip_nulls documentation
Further fix for json_strip_nulls documentation Oversight in commit 4603903d294. Author: Shinoda, Noriyoshi (SXD Japan FSI) Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e33969abc1934cc7fd92d539e51a2b8ae46d6a33 Modified Files -- doc/src/sgml/func.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix some performance issues in GIN query startup.
Fix some performance issues in GIN query startup. If a GIN index search had a lot of search keys (for example, "jsonbcol ?| array[]" with tens of thousands of array elements), both ginFillScanKey() and startScanKey() took O(N^2) time. Worse, those loops were uncancelable for lack of CHECK_FOR_INTERRUPTS. The problem in ginFillScanKey() is the brute-force search key de-duplication done in ginFillScanEntry(). The most expedient solution seems to be to just stop trying to de-duplicate once there are "too many" search keys. We could imagine working harder, say by using a sort-and-unique algorithm instead of brute force compare-all-the-keys. But it seems unlikely to be worth the trouble. There is no correctness issue here, since the code already allowed duplicate keys if any extra_data is present. The problem in startScanKey() is the loop that attempts to identify the first non-required search key. In the submitted test case, that vainly tests all the key positions, and each iteration takes O(N) time. One part of that is that it's reinitializing the entryRes[] array from scratch each time, which is entirely unnecessary given that the triConsistentFn isn't supposed to scribble on its input. We can easily adjust the array contents incrementally instead. The other part of it is that the triConsistentFn may itself take O(N) time (and does in this test case). This is all extremely brute force: in simple cases with AND or OR semantics, we could know without any looping whatever that all or none of the keys are required. But GIN opclasses don't have any API for exposing that knowledge, so at least in the short run there is little to be done about that. Put in a CHECK_FOR_INTERRUPTS so that at least the loop is cancelable. These two changes together resolve the primary complaint that the test query doesn't respond promptly to cancel interrupts. Also, while they don't completely eliminate the O(N^2) behavior, they do provide quite a nice speedup for mid-sized examples. Bug: #18831 Reported-by: Niek Author: Tom Lane Discussion: https://postgr.es/m/18831-e845ac44ebc5d...@postgresql.org Backpatch-through: 13 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2d313375c092d5bbe67539bfa3c1630808339f89 Modified Files -- src/backend/access/gin/ginget.c | 10 ++ src/backend/access/gin/ginscan.c | 7 ++- 2 files changed, 12 insertions(+), 5 deletions(-)
pgsql: valgrind: Adjust suppressions to handle glibc changes
valgrind: Adjust suppressions to handle glibc changes In newer glibc versions two additional functions appear between send() and socketcall.send(msg): fun:__internal_syscall_cancel fun:__syscall_cancel Due to that our existing suppression do not work anymore. Use '...', like aleady used in other suppressions, to make valgrind ignore these interstitial frames. The problematic suppressions are only in < 15, as they aren't needed after 5891c7a8ed8. Discussion: https://postgr.es/m/d7pyc6wbo2rqhfk24lsgz37766n75vty4jxy5dnppny7ezd4qc@56juadvntebw Backpatch-through: 13 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/33b02bfac4777a80151a564d751651c6efba002a Modified Files -- src/tools/valgrind.supp | 2 ++ 1 file changed, 2 insertions(+)
