pgsql: Fix comment in 024_add_drop_pub.pl
Fix comment in 024_add_drop_pub.pl A comment of the test was referring to an incorrect table. Thinko in 1046a69b3087. Extracted from a larger patch by the same author. Author: Alexander Lakhin Discussion: https://postgr.es/m/70b340bc-244a-589d-ef8b-d8aebb707...@gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/53785d2a2aaa7899eb82fb4eba9af6da83680c8d Modified Files -- src/test/subscription/t/024_add_drop_pub.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Improve stability of subscription/029_on_error.pl
Improve stability of subscription/029_on_error.pl This test was failing when using wal_debug=on and -DWAL_DEBUG because of additional log entries that made the test grab an LSN not mapping with the error expected in the test. Previously the test would look for the first matching line to get the LSN to skip up to. This is improved by having the test scan the logs with a regexp that checks for the expected ERROR string, ensuring that the wanted LSN comes from the correct context. Backpatch down to 15 where this test has been introduced. Author: Ian Ilyasov Discussion: https://postgr.es/m/gv1p251mb100415f17e6b2fdd7188777ecd...@gv1p251mb1004.eurp251.prod.outlook.com Backpatch-through: 15 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8e16f81f3db4eb03ac2195e9e5527852047c14a0 Modified Files -- src/test/subscription/t/029_on_error.pl | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
pgsql: Improve stability of subscription/029_on_error.pl
Improve stability of subscription/029_on_error.pl This test was failing when using wal_debug=on and -DWAL_DEBUG because of additional log entries that made the test grab an LSN not mapping with the error expected in the test. Previously the test would look for the first matching line to get the LSN to skip up to. This is improved by having the test scan the logs with a regexp that checks for the expected ERROR string, ensuring that the wanted LSN comes from the correct context. Backpatch down to 15 where this test has been introduced. Author: Ian Ilyasov Discussion: https://postgr.es/m/gv1p251mb100415f17e6b2fdd7188777ecd...@gv1p251mb1004.eurp251.prod.outlook.com Backpatch-through: 15 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/338fb8714c6cfe30c567ecb79812ec3879bd117f Modified Files -- src/test/subscription/t/029_on_error.pl | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
pgsql: Improve stability of subscription/029_on_error.pl
Improve stability of subscription/029_on_error.pl This test was failing when using wal_debug=on and -DWAL_DEBUG because of additional log entries that made the test grab an LSN not mapping with the error expected in the test. Previously the test would look for the first matching line to get the LSN to skip up to. This is improved by having the test scan the logs with a regexp that checks for the expected ERROR string, ensuring that the wanted LSN comes from the correct context. Backpatch down to 15 where this test has been introduced. Author: Ian Ilyasov Discussion: https://postgr.es/m/gv1p251mb100415f17e6b2fdd7188777ecd...@gv1p251mb1004.eurp251.prod.outlook.com Backpatch-through: 15 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ac8c85d04b133509071b1de60a027ebe00654696 Modified Files -- src/test/subscription/t/029_on_error.pl | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
pgsql: Fix typo and comments related to the recent no-wait lock improve
Fix typo and comments related to the recent no-wait lock improvements The argument of dontWait at the top of ProcSleep() was documented backwards, and there was a typo in lock.c. Thinkos in 2346df6fc373. Author: Will Mortensen Reviewed-by: Jingxian Li, Michael Paquier Discussion: https://postgr.es/m/campnoc5f+eis7tdy8pupd_lacstvt-pypvookfjhrqqmkhp...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f7ab71ba0c7bcf237403d40269aeea0a0f2551df Modified Files -- src/backend/storage/lmgr/lock.c | 2 +- src/backend/storage/lmgr/proc.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
pgsql: doc: Fix column_name parameter in ALTER MATERIALIZED VIEW
doc: Fix column_name parameter in ALTER MATERIALIZED VIEW Parameter column_name must be an existing column because ALTER MATERIALIZED VIEW cannot add new columns. The old description was likely copied from ALTER TABLE. Author: Erik Wienhold Discussion: https://postgr.es/m/6880ca53-7961-4eeb-86d5-6bd05fc20...@ewie.name Backpatch-through: 12 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/dd087e1c13bf5f2bcfdc189976aa4e44ed431739 Modified Files -- doc/src/sgml/ref/alter_materialized_view.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: doc: Fix column_name parameter in ALTER MATERIALIZED VIEW
doc: Fix column_name parameter in ALTER MATERIALIZED VIEW Parameter column_name must be an existing column because ALTER MATERIALIZED VIEW cannot add new columns. The old description was likely copied from ALTER TABLE. Author: Erik Wienhold Discussion: https://postgr.es/m/6880ca53-7961-4eeb-86d5-6bd05fc20...@ewie.name Backpatch-through: 12 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c0acf25a5cf2d62b60d82e5bb0c553ce9c05a51d Modified Files -- doc/src/sgml/ref/alter_materialized_view.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: doc: Fix column_name parameter in ALTER MATERIALIZED VIEW
doc: Fix column_name parameter in ALTER MATERIALIZED VIEW Parameter column_name must be an existing column because ALTER MATERIALIZED VIEW cannot add new columns. The old description was likely copied from ALTER TABLE. Author: Erik Wienhold Discussion: https://postgr.es/m/6880ca53-7961-4eeb-86d5-6bd05fc20...@ewie.name Backpatch-through: 12 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0c6b6498131e0552d5bb120bdcbf72ffbcd524fa Modified Files -- doc/src/sgml/ref/alter_materialized_view.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: doc: Fix column_name parameter in ALTER MATERIALIZED VIEW
doc: Fix column_name parameter in ALTER MATERIALIZED VIEW Parameter column_name must be an existing column because ALTER MATERIALIZED VIEW cannot add new columns. The old description was likely copied from ALTER TABLE. Author: Erik Wienhold Discussion: https://postgr.es/m/6880ca53-7961-4eeb-86d5-6bd05fc20...@ewie.name Backpatch-through: 12 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c0df15ac7e9ef3870da50fde49c658290f7a0da6 Modified Files -- doc/src/sgml/ref/alter_materialized_view.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: doc: Fix column_name parameter in ALTER MATERIALIZED VIEW
doc: Fix column_name parameter in ALTER MATERIALIZED VIEW Parameter column_name must be an existing column because ALTER MATERIALIZED VIEW cannot add new columns. The old description was likely copied from ALTER TABLE. Author: Erik Wienhold Discussion: https://postgr.es/m/6880ca53-7961-4eeb-86d5-6bd05fc20...@ewie.name Backpatch-through: 12 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/961608636461e259487223237147ce447672deaa Modified Files -- doc/src/sgml/ref/alter_materialized_view.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: doc: Fix column_name parameter in ALTER MATERIALIZED VIEW
doc: Fix column_name parameter in ALTER MATERIALIZED VIEW Parameter column_name must be an existing column because ALTER MATERIALIZED VIEW cannot add new columns. The old description was likely copied from ALTER TABLE. Author: Erik Wienhold Discussion: https://postgr.es/m/6880ca53-7961-4eeb-86d5-6bd05fc20...@ewie.name Backpatch-through: 12 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b4f808467a56b69838730164df5a22f946087b82 Modified Files -- doc/src/sgml/ref/alter_materialized_view.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Remove enum WaitEventExtension
Remove enum WaitEventExtension This enum was used to determine the first ID to use when assigning a custom wait event for extensions, which is always 1. It was kept so as it would be possible to add new in-core wait events in the category "Extension". There is no such thing currently, so let's remove this enum until a case justifying it pops up. This makes the code simpler and easier to understand. This has as effect to switch back autoprewarm.c to use PG_WAIT_EXTENSION rather than WAIT_EVENT_EXTENSION, on par with v16 and older stable branches. Thinko in c9af05465307. Reported-by: Peter Eisentraut Discussion: https://postgr.es/m/195c6c45-abce-4331-be6a-e87724e1d...@eisentraut.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/110eb4aefbad683c8f512ee8a7168d1718353baa Modified Files -- contrib/pg_prewarm/autoprewarm.c| 4 ++-- src/backend/utils/activity/wait_event.c | 7 +++ src/include/utils/wait_event.h | 6 -- src/tools/pgindent/typedefs.list| 1 - 4 files changed, 5 insertions(+), 13 deletions(-)
pgsql: doc: Mention more variant --name=value of -c name=value for post
doc: Mention more variant --name=value of -c name=value for postgres postgres --name=value and -c name=value are equivalents. This commit expands the documentation of libpq's "option" connection parameter and the server startup sequence for shell interactions to mention both rather than only -c. Extracted from a larger patch by the same authors. Reported-by: Alexey Palazhchenko Author: David Johnston, Aleksander Alekseev Reviewed-by: Nathan Bossart, Peter Eisentraut, Álvaro Herrera Discussion: https://postgr.es/m/CAJ7c6TMkuLiLfrA+EFCPYfhXoMKRxxssB5c86+ibxfaz6+=s...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f01e3ba56fd125ccba65b23a1829fc25b6f3fc65 Modified Files -- doc/src/sgml/config.sgml | 11 ++- doc/src/sgml/libpq.sgml | 7 --- 2 files changed, 10 insertions(+), 8 deletions(-)
pgsql: Add missing newline at the end of index_including.sql
Add missing newline at the end of index_including.sql Thinko in a63224be49b8. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/54b69f1bd730a228a666441592a12d2a0cbe2a06 Modified Files -- src/test/regress/sql/index_including.sql | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: injection_points: Store runtime conditions in private area
injection_points: Store runtime conditions in private area This commit fixes a race condition between injection point run and detach, where a point detached by a backend and concurrently running in a second backend could cause the second backend to do an incorrect condition check. This issue happens because the second backend retrieves the callback information in a first step in the shmem hash table for injection points, and the condition in a second step within the callback. If the point is detached between these two steps, the condition would be removed, causing the point to run while it should not. Storing the condition in the new private_data area introduced in 33181b48fd0e ensures that the condition retrieved is consistent with its callback. This commit leads to a lot of simplifications in the module injection_points, as there is no need to handle the runtime conditions inside it anymore. Runtime conditions have no more a maximum number. Per discussion with Noah Misch. Reviewed-by: Noah Misch Discussion: https://postgr.es/m/20240509031553...@rfd.leadboat.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/267d41dc4f4184525353db4069709cfb3df02ceb Modified Files -- .../modules/injection_points/injection_points.c| 173 +++-- src/tools/pgindent/typedefs.list | 1 + 2 files changed, 61 insertions(+), 113 deletions(-)
pgsql: Introduce private data area for injection points
Introduce private data area for injection points This commit extends the backend-side infrastructure of injection points so as it becomes possible to register some input data when attaching a point. This private data can be registered with the function name and the library name of the callback when attaching a point, then it is given as input argument to the callback. This gives the possibility for modules to pass down custom data at runtime when attaching a point without managing that internally, in a manner consistent with the callback entry retrieved from the hash shmem table storing the injection point data. InjectionPointAttach() gains two arguments, to be able to define the private data contents and its size. A follow-up commit will rely on this infrastructure to close a race condition with the injection point detach in the module injection_points. While on it, this changes InjectionPointDetach() to return a boolean, returning false if a point cannot be detached. This has been mentioned by Noah as useful when it comes to implement more complex tests with concurrent point detach, solid with the automatic detach done for local points in the test module. Documentation is adjusted in consequence. Per discussion with Noah Misch. Reviewed-by: Noah Misch Discussion: https://postgr.es/m/20240509031553...@rfd.leadboat.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/33181b48fd0ee62bc0a9e39291d5a5c4f8540354 Modified Files -- doc/src/sgml/xfunc.sgml| 14 -- src/backend/utils/misc/injection_point.c | 55 +- src/include/utils/injection_point.h| 9 ++-- .../injection_points/expected/injection_points.out | 2 +- .../modules/injection_points/injection_points.c| 22 + 5 files changed, 74 insertions(+), 28 deletions(-)
pgsql: Fix overread in JSON parsing errors for incomplete byte sequence
Fix overread in JSON parsing errors for incomplete byte sequences json_lex_string() relies on pg_encoding_mblen_bounded() to point to the end of a JSON string when generating an error message, and the input it uses is not guaranteed to be null-terminated. It was possible to walk off the end of the input buffer by a few bytes when the last bytes consist of an incomplete multi-byte sequence, as token_terminator would point to a location defined by pg_encoding_mblen_bounded() rather than the end of the input. This commit switches token_terminator so as the error uses data up to the end of the JSON input. More work should be done so as this code could rely on an equivalent of report_invalid_encoding() so as incorrect byte sequences can show in error messages in a readable form. This requires work for at least two cases in the JSON parsing API: an incomplete token and an invalid escape sequence. A more complete solution may be too invasive for a backpatch, so this is left as a future improvement, taking care of the overread first. A test is added on HEAD as test_json_parser makes this issue straight-forward to check. Note that pg_encoding_mblen_bounded() no longer has any callers. This will be removed on HEAD with a separate commit, as this is proving to encourage unsafe coding. Author: Jacob Champion Discussion: https://postgr.es/m/caoymi+ncm7pwls3ankcsmoqqtpjva8wmcdobtka3zrb2hzg...@mail.gmail.com Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/377c25d32275a65043f9dcf3d4668a56c37319e2 Modified Files -- src/common/jsonapi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
pgsql: Fix overread in JSON parsing errors for incomplete byte sequence
Fix overread in JSON parsing errors for incomplete byte sequences json_lex_string() relies on pg_encoding_mblen_bounded() to point to the end of a JSON string when generating an error message, and the input it uses is not guaranteed to be null-terminated. It was possible to walk off the end of the input buffer by a few bytes when the last bytes consist of an incomplete multi-byte sequence, as token_terminator would point to a location defined by pg_encoding_mblen_bounded() rather than the end of the input. This commit switches token_terminator so as the error uses data up to the end of the JSON input. More work should be done so as this code could rely on an equivalent of report_invalid_encoding() so as incorrect byte sequences can show in error messages in a readable form. This requires work for at least two cases in the JSON parsing API: an incomplete token and an invalid escape sequence. A more complete solution may be too invasive for a backpatch, so this is left as a future improvement, taking care of the overread first. A test is added on HEAD as test_json_parser makes this issue straight-forward to check. Note that pg_encoding_mblen_bounded() no longer has any callers. This will be removed on HEAD with a separate commit, as this is proving to encourage unsafe coding. Author: Jacob Champion Discussion: https://postgr.es/m/caoymi+ncm7pwls3ankcsmoqqtpjva8wmcdobtka3zrb2hzg...@mail.gmail.com Backpatch-through: 13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/855517307db8efd397d49163d65a4fd3bdcc41bc Modified Files -- src/common/jsonapi.c | 4 ++-- src/test/modules/test_json_parser/t/002_inline.pl | 8 2 files changed, 10 insertions(+), 2 deletions(-)
pgsql: Fix overread in JSON parsing errors for incomplete byte sequence
Fix overread in JSON parsing errors for incomplete byte sequences json_lex_string() relies on pg_encoding_mblen_bounded() to point to the end of a JSON string when generating an error message, and the input it uses is not guaranteed to be null-terminated. It was possible to walk off the end of the input buffer by a few bytes when the last bytes consist of an incomplete multi-byte sequence, as token_terminator would point to a location defined by pg_encoding_mblen_bounded() rather than the end of the input. This commit switches token_terminator so as the error uses data up to the end of the JSON input. More work should be done so as this code could rely on an equivalent of report_invalid_encoding() so as incorrect byte sequences can show in error messages in a readable form. This requires work for at least two cases in the JSON parsing API: an incomplete token and an invalid escape sequence. A more complete solution may be too invasive for a backpatch, so this is left as a future improvement, taking care of the overread first. A test is added on HEAD as test_json_parser makes this issue straight-forward to check. Note that pg_encoding_mblen_bounded() no longer has any callers. This will be removed on HEAD with a separate commit, as this is proving to encourage unsafe coding. Author: Jacob Champion Discussion: https://postgr.es/m/caoymi+ncm7pwls3ankcsmoqqtpjva8wmcdobtka3zrb2hzg...@mail.gmail.com Backpatch-through: 13 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5396a2987cc679a3ab5db26b54c8b76149489e29 Modified Files -- src/common/jsonapi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix overread in JSON parsing errors for incomplete byte sequence
Fix overread in JSON parsing errors for incomplete byte sequences json_lex_string() relies on pg_encoding_mblen_bounded() to point to the end of a JSON string when generating an error message, and the input it uses is not guaranteed to be null-terminated. It was possible to walk off the end of the input buffer by a few bytes when the last bytes consist of an incomplete multi-byte sequence, as token_terminator would point to a location defined by pg_encoding_mblen_bounded() rather than the end of the input. This commit switches token_terminator so as the error uses data up to the end of the JSON input. More work should be done so as this code could rely on an equivalent of report_invalid_encoding() so as incorrect byte sequences can show in error messages in a readable form. This requires work for at least two cases in the JSON parsing API: an incomplete token and an invalid escape sequence. A more complete solution may be too invasive for a backpatch, so this is left as a future improvement, taking care of the overread first. A test is added on HEAD as test_json_parser makes this issue straight-forward to check. Note that pg_encoding_mblen_bounded() no longer has any callers. This will be removed on HEAD with a separate commit, as this is proving to encourage unsafe coding. Author: Jacob Champion Discussion: https://postgr.es/m/caoymi+ncm7pwls3ankcsmoqqtpjva8wmcdobtka3zrb2hzg...@mail.gmail.com Backpatch-through: 13 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/41adf9d960c0105ada615574126d5568d552f4db Modified Files -- src/common/jsonapi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
pgsql: Fix overread in JSON parsing errors for incomplete byte sequence
Fix overread in JSON parsing errors for incomplete byte sequences json_lex_string() relies on pg_encoding_mblen_bounded() to point to the end of a JSON string when generating an error message, and the input it uses is not guaranteed to be null-terminated. It was possible to walk off the end of the input buffer by a few bytes when the last bytes consist of an incomplete multi-byte sequence, as token_terminator would point to a location defined by pg_encoding_mblen_bounded() rather than the end of the input. This commit switches token_terminator so as the error uses data up to the end of the JSON input. More work should be done so as this code could rely on an equivalent of report_invalid_encoding() so as incorrect byte sequences can show in error messages in a readable form. This requires work for at least two cases in the JSON parsing API: an incomplete token and an invalid escape sequence. A more complete solution may be too invasive for a backpatch, so this is left as a future improvement, taking care of the overread first. A test is added on HEAD as test_json_parser makes this issue straight-forward to check. Note that pg_encoding_mblen_bounded() no longer has any callers. This will be removed on HEAD with a separate commit, as this is proving to encourage unsafe coding. Author: Jacob Champion Discussion: https://postgr.es/m/caoymi+ncm7pwls3ankcsmoqqtpjva8wmcdobtka3zrb2hzg...@mail.gmail.com Backpatch-through: 13 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8c3f30e675e972e3c2750ea82781f2c4ba77a9f8 Modified Files -- src/common/jsonapi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
pgsql: injection_points: Fix incorrect spinlock acquisition
injection_points: Fix incorrect spinlock acquisition Injection points created under injection_points_set_local() are cleaned up by a shmem_exit() callback. The spinlock used by the module would be hold while calling InjectionPointDetach(), which is incorrect as spinlocks should avoid external calls while hold. This commit changes the shmem_exit() callback to detach the points in three steps with the spinlock acquired twice, knowing that the injection points should be around with the conditions related to them: - Scans for the points to detach in a first loop, while holding the spinlock. - Detach them. - Remove the registered conditions. It is still possible for other processes to detach local points concurrently of the callback. I have wanted to restrict the detach, but Noah has mentioned that he has in mind some cases that may require this capability. No tests in the tree based on injection points need that currently. Thinko in f587338dec87. Reported-by: Noah Misch Reviewed-by: Noah Misch Discussion: https://postgr.es/m/20240501231214...@rfd.leadboat.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/597f66942d0b18f2f15b478346bc74ae6fdb793b Modified Files -- .../modules/injection_points/injection_points.c| 31 -- 1 file changed, 29 insertions(+), 2 deletions(-)
pgsql: Add tab completion for EXPLAIN (MEMORY|SERIALIZE)
Add tab completion for EXPLAIN (MEMORY|SERIALIZE) SERIALIZE has been added in 06286709ee06, and MEMORY in 5de890e3610d. Author: Jian He Discussion: https://postgr.es/m/cacjufxh5ubhbcg-omt7phomvnabf2x48jfefu24fexsqvgz...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2800fbb2b793fcb45d9d72ca60f7534722ebc4cd Modified Files -- src/bin/psql/tab-complete.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-)
pgsql: doc: Remove one example related to pg_input_error_info()
doc: Remove one example related to pg_input_error_info() This slightly bloated the contents of the function table for this entry, without really bringing extra value. Per discussion with Jian He and David G. Johnston. Discussion: https://postgr.es/m/CACJufxGdyoBJQMSxwdxNK=k8m5wuth5fdfd4wq_k4f7+1j2...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f6ab942f5de003f37b88580154ebb614655d7e11 Modified Files -- doc/src/sgml/func.sgml | 11 +-- 1 file changed, 1 insertion(+), 10 deletions(-)
pgsql: Make two-phase tests of ECPG and main suite more concurrent-proo
Make two-phase tests of ECPG and main suite more concurrent-proof The ECPG and main 2PC tests have been using rather-generic names for the prepared transactions they generate. This commit switches the 2PC transactions to use more complex GIDs, reducing the risk of naming conflicts. The main 2PC tests also include scans of pg_prepared_xacts that do not apply filters on the GID of the prepared transactions, making it possible to fail the test when any 2PC transaction runs concurrently. The CI has been able to see such failures with an installcheck running the ECPG and the main regression test suites in parallel. The queries on pg_prepared_xacts gain quals to only look after the GIDs generated locally. The race is very hard to reproduce, so no backbatch is done for now. Reported-by: Richard Guo Discussion: https://postgr.es/m/CAMbWs4-mWCGbbE_bne5=afqjygdauzmjcw2+soljrdna0xu...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7e61e4cc7cfcf2a34f063094aeab01fdba7b65f6 Modified Files -- src/interfaces/ecpg/test/expected/sql-twophase.c | 4 +- .../ecpg/test/expected/sql-twophase.stderr | 4 +- src/interfaces/ecpg/test/sql/twophase.pgc | 4 +- src/test/regress/expected/prepared_xacts.out | 98 +++--- src/test/regress/expected/prepared_xacts_1.out | 62 +++--- src/test/regress/sql/prepared_xacts.sql| 50 +-- 6 files changed, 111 insertions(+), 111 deletions(-)
pgsql: Improve comment of DeallocateStmt->isall
Improve comment of DeallocateStmt->isall This field is not used directly in the code, but it is important for query jumbling to be able to make a difference between a named DEALLOCATE and DEALLOCATE ALL (see bb45156f342c). This behavior is tracked in the regression tests of pg_stat_statements, but the reason why this field is important can be easily missed, as a recent discussion has proved, so let's improve its comment to document the reason why it needs to be around. Wording has been suggested by Tom Lane Discussion: https://postgr.es/m/zih1att37yfda...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ee3ef4af19d8ba140a8b33c6598d470d36eec10c Modified Files -- src/include/nodes/parsenodes.h | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-)
pgsql: Fix dumps of partitioned tables with table AMs
Fix dumps of partitioned tables with table AMs pg_dump/restore failed to properly set the table access method for partitioned tables, as it relies on SET queries that would change default_table_access_method. However, SET affects only tables and materialized views, not partitioned tables which would always be restored with their pg_class.relam set to 0, losing their table AM set by either a CREATE TABLE .. USING or by a ALTER TABLE .. SET ACCESS METHOD. Appending a USING clause to the definition of CREATE TABLE is not possible as users may specify --no-table-access-method at restore or for a dump, meaning that the table AM portions may have to be skipped. Rather than SET, the solution used by this commit is to generate an extra ALTER TABLE .. SET ACCESS METHOD when restoring a partitioned table, based on the table AM set in its TOC entry. The choice of using a SET query or an ALTER TABLE query for a relation requires the addition of the relkind to the TOC entry to be able to choose between one or the other. Note that using ALTER TABLE SET ACCESS METHOD on a relation with physical storage would require a full rewrite, which would be costly for one. This also creates problems with binary upgrades where the rewrite would not be able to keep the OID of the relation consistent across the upgrade. This commit would normally require a protocol bump, but a45c78e3284b has already done one for this release cycle. Regression tests are adjusted with the new expected output, with some tweaks for the table AMs of the partitions to make the output more readable. Issue introduced by 374c7a229042, that has added support for table AMs in partitioned tables. Author: Michael Paquier Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/zh4jlsvvtqgbj...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f46bee346c3b6aab0a0f3f39dc734732b79ce1ed Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 70 ++-- src/bin/pg_dump/pg_backup_archiver.h | 5 ++- src/bin/pg_dump/pg_dump.c| 1 + src/bin/pg_dump/t/002_pg_dump.pl | 12 +++ 4 files changed, 79 insertions(+), 9 deletions(-)
pgsql: Remove resowner_private.h
Remove resowner_private.h This header is not used since the refactoring of resource owners done in b8bff07daa85, and all the functions declared in it became (well, mostly) static inline local to each resowner kind's code path. Author: Xing Guo Discussion: https://postgr.es/m/CACpMh+BFmtK5Z=b6pvh4hlkhupwa_vtrtzsrb4-yk-tqejp...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/06a0f4d52be3a52a74725dd29c66cd486256a209 Modified Files -- src/include/utils/resowner_private.h | 117 --- 1 file changed, 117 deletions(-)
pgsql: Fix typos with function name in event_trigger.c
Fix typos with function name in event_trigger.c Databases exist, contrary to datatabases. Oversight in e83d1b0c40cc. Author: Japin Li Discussion: https://postgr.es/m/me3p282mb316611a2f7bf43919f695228b6...@me3p282mb3166.ausp282.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/91fe092a966e6c08c0ead80388f474ac989dc9a3 Modified Files -- src/backend/commands/event_trigger.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-)
pgsql: xml2: Replace deprecated routines with recommended ones
xml2: Replace deprecated routines with recommended ones Some functions are used in the tree and are currently marked as deprecated by upstream. This commit refreshes the code to use the recommended functions, leading to the following changes: - xmlSubstituteEntitiesDefault() is gone, and needs to be replaced with XML_PARSE_NOENT for the paths doing the parsing. - xmlParseMemory() -> xmlReadMemory(). These functions, as well as more functions setting global states, have been officially marked as deprecated by upstream in August 2022. Their replacements exist since the 2001-ish area, as far as I have checked, so that should be safe. This has been originally applied as 65c5864d7fac without a backpatch, and this has come up as well when working on 400928b83. Per request from Tom Lane, for new buildfarm member indri that is able to see deprecation warnings with xmlSubstituteEntitiesDefault() in 16 and older stable branches. Author: Dmitry Koval Discussion: https://postgr.es/m/18274-98d16bc035206...@postgresql.org Discussion: https://postgr.es/m/1012981.1713222...@sss.pgh.pa.us Bakpatch-through: 12 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7c93f31dee5ff740b1367db472e69cdd290d8de2 Modified Files -- contrib/xml2/xpath.c | 11 ++- contrib/xml2/xslt_proc.c | 10 ++ 2 files changed, 12 insertions(+), 9 deletions(-)
pgsql: xml2: Replace deprecated routines with recommended ones
xml2: Replace deprecated routines with recommended ones Some functions are used in the tree and are currently marked as deprecated by upstream. This commit refreshes the code to use the recommended functions, leading to the following changes: - xmlSubstituteEntitiesDefault() is gone, and needs to be replaced with XML_PARSE_NOENT for the paths doing the parsing. - xmlParseMemory() -> xmlReadMemory(). These functions, as well as more functions setting global states, have been officially marked as deprecated by upstream in August 2022. Their replacements exist since the 2001-ish area, as far as I have checked, so that should be safe. This has been originally applied as 65c5864d7fac without a backpatch, and this has come up as well when working on 400928b83. Per request from Tom Lane, for new buildfarm member indri that is able to see deprecation warnings with xmlSubstituteEntitiesDefault() in 16 and older stable branches. Author: Dmitry Koval Discussion: https://postgr.es/m/18274-98d16bc035206...@postgresql.org Discussion: https://postgr.es/m/1012981.1713222...@sss.pgh.pa.us Bakpatch-through: 12 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/689ba4f1c4067005af0a71ba0cc52365474c4e4a Modified Files -- contrib/xml2/xpath.c | 11 ++- contrib/xml2/xslt_proc.c | 10 ++ 2 files changed, 12 insertions(+), 9 deletions(-)
pgsql: xml2: Replace deprecated routines with recommended ones
xml2: Replace deprecated routines with recommended ones Some functions are used in the tree and are currently marked as deprecated by upstream. This commit refreshes the code to use the recommended functions, leading to the following changes: - xmlSubstituteEntitiesDefault() is gone, and needs to be replaced with XML_PARSE_NOENT for the paths doing the parsing. - xmlParseMemory() -> xmlReadMemory(). These functions, as well as more functions setting global states, have been officially marked as deprecated by upstream in August 2022. Their replacements exist since the 2001-ish area, as far as I have checked, so that should be safe. This has been originally applied as 65c5864d7fac without a backpatch, and this has come up as well when working on 400928b83. Per request from Tom Lane, for new buildfarm member indri that is able to see deprecation warnings with xmlSubstituteEntitiesDefault() in 16 and older stable branches. Author: Dmitry Koval Discussion: https://postgr.es/m/18274-98d16bc035206...@postgresql.org Discussion: https://postgr.es/m/1012981.1713222...@sss.pgh.pa.us Bakpatch-through: 12 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6fa5e67e832bbab80ea7b936701e2c03c22fe059 Modified Files -- contrib/xml2/xpath.c | 14 -- contrib/xml2/xslt_proc.c | 10 ++ 2 files changed, 14 insertions(+), 10 deletions(-)
pgsql: xml2: Replace deprecated routines with recommended ones
xml2: Replace deprecated routines with recommended ones Some functions are used in the tree and are currently marked as deprecated by upstream. This commit refreshes the code to use the recommended functions, leading to the following changes: - xmlSubstituteEntitiesDefault() is gone, and needs to be replaced with XML_PARSE_NOENT for the paths doing the parsing. - xmlParseMemory() -> xmlReadMemory(). These functions, as well as more functions setting global states, have been officially marked as deprecated by upstream in August 2022. Their replacements exist since the 2001-ish area, as far as I have checked, so that should be safe. This has been originally applied as 65c5864d7fac without a backpatch, and this has come up as well when working on 400928b83. Per request from Tom Lane, for new buildfarm member indri that is able to see deprecation warnings with xmlSubstituteEntitiesDefault() in 16 and older stable branches. Author: Dmitry Koval Discussion: https://postgr.es/m/18274-98d16bc035206...@postgresql.org Discussion: https://postgr.es/m/1012981.1713222...@sss.pgh.pa.us Bakpatch-through: 12 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bb418aeee27078e2f3955a131515c151173143bd Modified Files -- contrib/xml2/xpath.c | 14 -- contrib/xml2/xslt_proc.c | 10 ++ 2 files changed, 14 insertions(+), 10 deletions(-)
pgsql: xml2: Replace deprecated routines with recommended ones
xml2: Replace deprecated routines with recommended ones Some functions are used in the tree and are currently marked as deprecated by upstream. This commit refreshes the code to use the recommended functions, leading to the following changes: - xmlSubstituteEntitiesDefault() is gone, and needs to be replaced with XML_PARSE_NOENT for the paths doing the parsing. - xmlParseMemory() -> xmlReadMemory(). These functions, as well as more functions setting global states, have been officially marked as deprecated by upstream in August 2022. Their replacements exist since the 2001-ish area, as far as I have checked, so that should be safe. This has been originally applied as 65c5864d7fac without a backpatch, and this has come up as well when working on 400928b83. Per request from Tom Lane, for new buildfarm member indri that is able to see deprecation warnings with xmlSubstituteEntitiesDefault() in 16 and older stable branches. Author: Dmitry Koval Discussion: https://postgr.es/m/18274-98d16bc035206...@postgresql.org Discussion: https://postgr.es/m/1012981.1713222...@sss.pgh.pa.us Bakpatch-through: 12 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4b0e5d6012918de2069a2636aacf60bbc6c0085c Modified Files -- contrib/xml2/xpath.c | 14 -- contrib/xml2/xslt_proc.c | 10 ++ 2 files changed, 14 insertions(+), 10 deletions(-)
Re: pgsql: Move code for backend startup to separate file
On Mon, Apr 15, 2024 at 05:24:39PM +0900, Michael Paquier wrote: > extern PGDLLIMPORT const char *progname; > > +extern bool LoadedSSL; > > This variable is missing a PGDLLIMPORT, it seems. > > aafc05de1bf5 has missed a second one with MyClientSocket. Both are > declared in postmaster.h. For now, I've fixed these two with 768ceeeaa127. -- Michael signature.asc Description: PGP signature
pgsql: Add missing PGDLLIMPORT markings
Add missing PGDLLIMPORT markings All backend-side variables should be marked with PGDLLIMPORT, as per policy introduced in 8ec569479f. aafc05de1bf5 has forgotten MyClientSocket, and 05c3980e7f47 LoadedSSL. These can be spotted with a command like this one (be careful of not switching __pg_log_level): src/tools/mark_pgdllimport.pl $(git ls-files src/include/) Reported-by: Peter Eisentraut Discussion: https://postgr.es/m/zhzkrzrkkhbeq...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/768ceeeaa127a8001d60ad6a62846a8be3f35d93 Modified Files -- src/include/postmaster/postmaster.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Re: pgsql: Move code for backend startup to separate file
Hi Heikki, (Peter E. in CC.) On Mon, Mar 18, 2024 at 09:40:36AM +, Heikki Linnakangas wrote: > Move code for backend startup to separate file > > This is code that runs in the backend process after forking, rather > than postmaster. Move it out of postmaster.c for clarity. > > Reviewed-by: Tristan Partin, Andres Freund > Discussion: > https://www.postgresql.org/message-id/7a59b073-5b5b-151e-7ed3-8b01ff7ce...@iki.fi --- a/src/include/postmaster/postmaster.h +++ b/src/include/postmaster/postmaster.h @@ -52,6 +52,8 @@ extern PGDLLIMPORT int postmaster_alive_fds[2]; extern PGDLLIMPORT const char *progname; +extern bool LoadedSSL; This variable is missing a PGDLLIMPORT, it seems. aafc05de1bf5 has missed a second one with MyClientSocket. Both are declared in postmaster.h. The credit goes to Peter Eisentraunt for noticing these two who has mentioned that to me on mastodon, while I am not able to parse correctly a set of diffs. This stuff can be spotted with a command like this one: src/tools/mark_pgdllimport.pl $(git ls-files *.h) Thanks, -- Michael signature.asc Description: PGP signature
pgsql: Use correct datatype for xmin variables in slot.c
Use correct datatype for xmin variables in slot.c Two variables storing a slot's effective_xmin and effective_catalog_xmin were saved as XLogRecPtr, which is incorrect as these should be TransactionIds. Oversight in 818fefd8fd44. Author: Bharath Rupireddy Discussion: https://postgr.es/m/calj2acvpsb74mrdtfezz-lv3oi6f3sn71qa0ouhvndzi5dw...@mail.gmail.com Backpatch-through: 16 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8f136af3c41c3b7e6474d6dd05238f11059f26f1 Modified Files -- src/backend/replication/slot.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Use correct datatype for xmin variables in slot.c
Use correct datatype for xmin variables in slot.c Two variables storing a slot's effective_xmin and effective_catalog_xmin were saved as XLogRecPtr, which is incorrect as these should be TransactionIds. Oversight in 818fefd8fd44. Author: Bharath Rupireddy Discussion: https://postgr.es/m/calj2acvpsb74mrdtfezz-lv3oi6f3sn71qa0ouhvndzi5dw...@mail.gmail.com Backpatch-through: 16 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/574c7c754666a2b5634efd700d3602629d261362 Modified Files -- src/backend/replication/slot.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Re: pgsql: Fix race leading to incorrect conflict cause in InvalidatePossib
On Thu, Apr 11, 2024 at 12:38:06PM +0530, Bharath Rupireddy wrote: > I found a typo with the code added by this commit - we've used > XLogRecPtr/InvalidXLogRecPtr for xmins in place of > TransactionId/InvalidTransactionId. Attached a patch to fix this. Thanks for the report. Will fix. -- Michael signature.asc Description: PGP signature
Re: pgsql: Fix potential stack overflow in incremental backup.
Hi Thomas, On Thu, Apr 11, 2024 at 01:53:24AM +, Thomas Munro wrote: > Fix potential stack overflow in incremental backup. > > The user can set RELSEG_SIZE to a high number at compile time, so we > can't use it to control the size of an array on the stack: it could be > many gigabytes in size. On closer inspection, we don't really need that > intermediate array anyway. Let's just write directly into the output > array, and then perform the absolute->relative adjustment in place. > This fixes new code from commit dc212340058. + * file just as if this were not an incremental backup. The contents of the + * relative_block_numbers array is unspecified in this case. Perhaps you mean s/is/are/ here? The contents are what's not specified. -- Michael signature.asc Description: PGP signature
pgsql: Fix inconsistency with replay of hash squeeze record for clean b
Fix inconsistency with replay of hash squeeze record for clean buffers aa5edbe379d6 has tweaked _hash_freeovflpage() so as the write buffer's LSN is updated only when necessary, when REGBUF_NO_CHANGE is not used. The replay code was not consistent with that, causing the write buffer's LSN to be updated and its page to be marked as dirty even if the buffer was registered in a "clean" state. This was possible for the case of a squeeze record when there are no tuples to add to the write buffer, for (is_prim_bucket_same_wrt && !is_prev_bucket_same_wrt). I have performed some validation of this commit with wal_consistency_checking and a change in WAL that logs REGBUF_NO_CHANGE to a new BKPIMAGE_*. Thanks to that, it is possible to know at replay if a buffer was clean when it was registered, then cross-checked the LSN of the "clean" page copy coming from WAL with the LSN of the block once the record has been replayed. This eats one bit in bimg_info, which is not acceptable to be integrated as-is, but it could become handy in the future. I didn't spot other areas than the one fixed by this commit at the extent of what the main regression test suite covers. As this is an oversight in aa5edbe379d6, no backpatch is required. Reported-by: Zubeyr Eryilmaz Author: Hayato Kuroda Reviewed-by: Amit Kapila, Michael Paquier Discussion: https://postgr.es/m/zbyvvg_7ew3yd...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f56a9def71bb1d2ccf4fa01a4d1e082c1063d921 Modified Files -- src/backend/access/hash/hash_xlog.c | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-)
pgsql: Make GIN tests using injection points concurrent-safe
Make GIN tests using injection points concurrent-safe f587338dec87 has introduced in the test module injection_points a SQL function called injection_points_set_local(), that can be used to make all the injection points linked to the process where they are attached, discarded automatically if any remain once the process exits. e2e3b8ae9ed7 has added a NO_INSTALLCHECK to the test module to prevent the use of installcheck. Now that there is a way to make the test concurrent-safe, let's use it and remove the installcheck restriction. Concurrency issues could be easily reproduced by running in a tight loop a command like this one, in src/test/modules/gin/ (hardcoding pg_sleep() after attaching injection points enlarges the race window) and a second test suite like contrib/btree_gin/: make installcheck USE_MODULE_DB=1 Reviewed-by: Andrey Borodin Discussion: https://postgr.es/m/zhng4io9uyogw...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5105c90796811f62711538155d207e5311eacf9b Modified Files -- src/test/modules/gin/Makefile | 3 --- src/test/modules/gin/expected/gin_incomplete_splits.out | 7 +++ src/test/modules/gin/meson.build| 2 -- src/test/modules/gin/sql/gin_incomplete_splits.sql | 3 +++ 4 files changed, 10 insertions(+), 5 deletions(-)
pgsql: Add missing set_pglocale_pgservice() for pg_walsummary and pg_co
Add missing set_pglocale_pgservice() for pg_walsummary and pg_combinebackup These calls are required to make both tools work with NLS. Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20240408.162702.183779935636035593.horikyota@gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/deca6ac136f4cd09280b3385dc5de3e8ec57e9ba Modified Files -- src/bin/pg_combinebackup/pg_combinebackup.c | 1 + src/bin/pg_walsummary/pg_walsummary.c | 1 + 2 files changed, 2 insertions(+)
pgsql: injection_points: Fix race condition with local injection point
injection_points: Fix race condition with local injection point tests The module relies on a shmem exit callback to clean up any injection points linked to a specific process. One of the tests checks for the case of an injection point name reused in a second connection where the first connection should clean it up, but it did not count for the fact that the shmem exit callback of the first connection may not have run when the second connection begins its work. The regress library includes a wait_pid() that can be used for this purpose, instead of a custom wait logic, so let's rely on it to wait for the first connection to exit before working with the second connection. The module gains a REGRESS_OPTS to be able to look at the regress library's dlpath. This issue could be reproduced with a hardcoded sleep() in the shmem exit callback, and the CI has been able to trigger it sporadically. Oversight in f587338dec87. Reported-by: Bharath Rupireddy Reviewed-by: Andrey Borodin Discussion: https://postgr.es/m/zhod3nxautteo...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f4083c49751018ae2140de8bf752b8d60485a6ca Modified Files -- src/test/modules/injection_points/Makefile | 1 + .../injection_points/expected/injection_points.out | 17 + src/test/modules/injection_points/meson.build | 1 + .../modules/injection_points/sql/injection_points.sql | 16 4 files changed, 35 insertions(+)
pgsql: injection_points: Introduce runtime conditions
injection_points: Introduce runtime conditions This adds a new SQL function injection_points_set_local() that can be used to force injection points to be run only in the process where they are attached. This is handy for SQL tests to: - Detach automatically injection points when the process exits. - Allow tests with injection points to run concurrently with other test suites, so as such modules do not have to be marked with NO_INSTALLCHECK. Currently, the only condition that can be registered is for a PID. This could be extended to more kinds later, if required, like database names/OIDs, roles, or more concepts I did not consider. Using a single function for SQL scripts is an idea from Heikki Linnakangas. Reviewed-by: Andrey Borodin Discussion: https://postgr.es/m/zfp7ids9tvrke...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f587338dec87d3c35b025e131c5977930ac69077 Modified Files -- .../injection_points/expected/injection_points.out | 77 + .../injection_points/injection_points--1.0.sql | 11 ++ .../modules/injection_points/injection_points.c| 176 + .../injection_points/sql/injection_points.sql | 20 +++ src/tools/pgindent/typedefs.list | 1 + 5 files changed, 285 insertions(+)
pgsql: Make GIN test using injection points repeatable
Make GIN test using injection points repeatable As written, the test would fail when run repeatedly because one of the injection points attached was not detached. This would not matter if the test is rewritten to be concurrently safe, but let's be clean and it is a good practice. Oversight in 6a1ea02c491d. Discussion: https://postgr.es/m/zfp7ids9tvrke...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/997db123c054c597164be77b7bf7da6479471621 Modified Files -- src/test/modules/gin/expected/gin_incomplete_splits.out | 6 ++ src/test/modules/gin/sql/gin_incomplete_splits.sql | 2 ++ 2 files changed, 8 insertions(+)
pgsql: Add "ABI_compatibility" regions to wait_event_names.txt
Add "ABI_compatibility" regions to wait_event_names.txt
The current design behind the automatic generation of the C code and
documentation related to wait events introduced in fa88928470b5 does not
offer a way to attach new wait events without breaking ABI
compatibility, as all the events are forcibly reordered for each section
in the input file wait_event_names.txt. Adding new wait events to
stable branches is something that has happened in the past, 0b6517a3b79a
being a recent example of that with VERSION_FILE_SYNC, so we need a way
to generate any C code for wait events while maintaining compatibility
on stable branches already released.
This commit solves this issue by adding a new region called
"ABI_compatibility" (keyword could be updated to something else if
someone had a better idea) to each section of wait_event_names.txt, so
as one can add new wait events to stable branches in
wait_event_names.txt while keeping the code ABI-compatible.
"ABI_compatibility" has no impact on the documentation generated: all
the wait events of one section are still alphabetically ordered. LWLock
and Lock sections generate their C code elsewhere, so they do not need
an "ABI_compatibility" region.
For example, let's imagine a wait_event_names.txt like that:
Section: ClassName - Foo
FOO_1 "Waiting in Foo 1"
FOO_2 "Waiting in Foo 2"
ABI_compatibility:
NEW_FOO_1 "Waiting in New Foo 1"
NEW_BAR_1 "Waiting in New Bar 1"
This results in the following enum, where the events in the ABI region
are listed last with the same ordering as in wait_event_names.txt:
typedef enum
{
WAIT_EVENT_FOO_1,
WAIT_EVENT_FOO_2,
WAIT_EVENT_NEW_FOO_1,
WAIT_EVENT_NEW_BAR_1
} WaitEventFoo;
New wait events added in stable branches should be added at the end of
each ABI_compatibility region, and ABI_compatibility should remain empty
on HEAD and unreleased stable branches.
This design has been suggested by Noah Misch and me.
Reported-by: Noah Misch
Author: Bertrand Drouvot
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/20240317183114...@rfd.leadboat.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/f98dbdeb51d1175c07258cd2bd4b56f560dfc3cf
Modified Files
--
.../utils/activity/generate-wait_event_types.pl| 28 +-
src/backend/utils/activity/wait_event_names.txt| 18 ++
2 files changed, 45 insertions(+), 1 deletion(-)
pgsql: Coordinate emit_log_hook and all log destinations to share the s
Coordinate emit_log_hook and all log destinations to share the same timeval This would cause the timestamp values used by emit_log_hook and all the other log destinations to differ, because the timestamps are reset before sending the logs to the server and after calling the hook. This change matters for emit_log_hook when generating log information with 'n' or 'm' in log_line_prefix through log_status_format(), or when doing direct calls to get_formatted_log_time() like in the JSON or CSV log formats. While on it, this commit fixes a couple of comments related to the formatted timestamps where the JSON was not mentioned. Oversight in dc686681e079, that I have noticed while reviewing this patch. Author: Kambam Vinay, Michael Paquier Discussion: https://postgr.es/m/canirfmsk36a0i8mnqtzaxhsm3cucimpwjpp4wqnq53odsnk...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2a217c371799ae3ecd8d32a137cea874fad7f5dc Modified Files -- src/backend/utils/error/elog.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-)
pgsql: pg_regress: Save errno in emit_tap_output_v() and switch to %m
pg_regress: Save errno in emit_tap_output_v() and switch to %m emit_tap_output_v() includes some fprintf() calls for some output related to the TAP protocol, that may clobber errno and break %m. This commit makes the logging of pg_regress smarter by saving errno before restoring it in vfprintf() where the input strings are used, removing the need for strerror(). All logs are switched to %m rather than strerror(), shaving some code. This was not a problem until now as pg_regress.c did not use %m, but the change is simple enough that we have no reason to not support this placeholder, and that will avoid future mistakes if new logs that include %m are added. Author: Dagfinn Ilmari Mannsåker Reviewed-by: Peter Eisentraunt, Michael Paquier Discussion: https://postgr.es/m/87sf13jhuw@wibble.ilmari.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/85230a247c74b92d9676abdf6693ac9d56c373cf Modified Files -- src/test/regress/pg_regress.c | 84 ++- 1 file changed, 34 insertions(+), 50 deletions(-)
pgsql: Remove references to backup_fs_hot() in Cluster.pm
Remove references to backup_fs_hot() in Cluster.pm This routine has been removed in 39969e2a1e4d with the exclusive backup mode but there were still references to it. Issue noticed while working on 071e3ad59d6f. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ca108be72e7abf1f801c8e49dcfff412c0d9 Modified Files -- src/test/perl/PostgreSQL/Test/Cluster.pm | 5 + 1 file changed, 1 insertion(+), 4 deletions(-)
Re: pgsql: Add TAP tests for timeouts
On Fri, Mar 15, 2024 at 11:20:49AM +0500, Andrey M. Borodin wrote: > And hachi sometimes pass this test too [0]. > > I’ll look more on this. Do I understand right that we have only 2 buildfarm > members with injection points? I have added --enable-injection-points to three of them: hachi, gokiburi and batta. The switch is also enabled in the CI by defaultm where you may be able to capture a bit more information than the buildfarm. -- Michael signature.asc Description: PGP signature
Re: pgsql: Add TAP tests for timeouts
On Fri, Mar 15, 2024 at 10:42:35AM +0900, Kyotaro Horiguchi wrote: > In 005_timeouts.pl, I found the following comment. Note also that the test is not stable, one of my machines with injection points enabled has complained twice in its last three runs: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hachi=2024-03-14%2015%3A05%3A04 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hachi=2024-03-15%2003%3A21%3A15 -- Michael signature.asc Description: PGP signature
pgsql: Add basic TAP tests for the low-level backup method, take two
Add basic TAP tests for the low-level backup method, take two There are currently no tests for the low-level backup method where pg_backup_start() and pg_backup_stop() are involved while taking a file-system backup. The tests introduced in this commit rely on a background psql process to make sure that the backup is taken while the session doing the SQL start and stop calls remains alive. Two cases are checked here with the backup taken: - Recovery without a backup_label, leading to a corrupted state. - Recovery with a backup_label, with a consistent state reached. Both cases cross-check some patterns in the logs generated when running recovery. Compared to the first attempt in 99b4a63bef94, this includes a couple of fixes making the CI stable (5 runs succeeded here): - Add the file to the list of tests in meson.build. - Race condition with the first WAL segment that we expect in the primary's archives, by adding a poll on pg_stat_archiver. The second segment with the checkpoint record is archived thanks to pg_backup_stop waiting for it. - Fix failure of test where the backup_label does not exist. The cluster inherits the configuration of the first node; it was attempting to store segments in the first node's archives, triggering failures with copy on Windows. - Fix failure of test on Windows because of incorrect parsing of the backup_file in the success case. The data of the backup_label file is retrieved from the output pg_backup_stop() from a BackgroundPsql written directly to the backup's data folder. This would include CRLFs (\r\n), causing the startup process to fail at the beginning of recovery when parsing the backup_label because only LFs (\n) are allowed. Author: David Steele Discussion: https://postgr.es/m/f20fcc82-dadb-478d-beb4-1e2ffb0ac...@pgmasters.net Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/071e3ad59d6fd2d6d1277b2bd9579397d10ded28 Modified Files -- src/test/recovery/meson.build | 1 + src/test/recovery/t/042_low_level_backup.pl | 144 2 files changed, 145 insertions(+)
pgsql: Refactor initial hash lookup in dynahash.c
Refactor initial hash lookup in dynahash.c The same pattern is used three times in dynahash.c to retrieve a bucket number and a hash bucket from a hash value. This has popped up while discussing improvements for the type cache, where this piece of refactoring would become useful. Note that hash_search_with_hash_value() does not need the bucket number, just the hash bucket. Author: Teodor Sigaev Reviewed-by: Aleksander Alekseev, Michael Paquier Discussion: https://postgr.es/m/5812a6e5-68ae-4d84-9d85-b44317696...@sigaev.ru Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cc5ef90edd809eaf85e11a0ee251229bbf7ce798 Modified Files -- src/backend/utils/hash/dynahash.c | 75 +-- 1 file changed, 33 insertions(+), 42 deletions(-)
pgsql: Revert "Add basic TAP tests for the low-level backup method"
Revert "Add basic TAP tests for the low-level backup method" This reverts commit 99b4a63bef94. The test is proving to be unstable, so revert it for now. One of the failures seen involves the cluster started without the backup_label, where the archives of the primary are overwritten, causing recovery failures on Windows. This is simple to fix, but there is another issue that's creeping behind in the form of an "invalid data in file" ERROR when parsing the backup_label for the second recovery case, as an effect of the backup_label data written after retrieving its contents from pg_backup_stop(). _ Per buildfarm member sidewinder. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6cb1b632b354518a595f1b23bfbac28a798f7f1c Modified Files -- src/test/recovery/t/042_low_level_backup.pl | 120 1 file changed, 120 deletions(-)
pgsql: Add basic TAP tests for the low-level backup method
Add basic TAP tests for the low-level backup method There are currently no tests for the low-level backup method where pg_backup_start() and pg_backup_stop() are involved while taking a file-system backup. The tests introduced in this commit rely on a background psql process to make sure that the backup is taken while the session doing the SQL start and stop calls remains alive. Two cases are checked here with the backup taken: - Recovery without a backup_label, leading to a corrupted state. - Recovery with a backup_label, with a consistent state reached. Both cases cross-check some patterns in the logs generated when running recovery. Author: David Steele Discussion: https://postgr.es/m/f20fcc82-dadb-478d-beb4-1e2ffb0ac...@pgmasters.net Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/99b4a63bef94b8e62a9a96c2446d1c16f95acd3b Modified Files -- src/test/recovery/t/042_low_level_backup.pl | 120 1 file changed, 120 insertions(+)
pgsql: Add tests for more row patterns with COPY FROM .. (ON_ERROR igno
Add tests for more row patterns with COPY FROM .. (ON_ERROR ignore) While digging into the code of this feature, I got confused by the fact that a line is skipped when a value cannot be converted to its expected attribute even if the line has fewer attributes than the target relation. The tests had a check for the case of an empty line, this commit a couple more patterns where a line is incomplete, but skipped because of a conversion error. Reviewed-by: Bharath Rupireddy Discussion: https://postgr.es/m/ze_7kzqexdt0b...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a189ed49d6292979be1478292246be61c4563043 Modified Files -- src/test/regress/expected/copy2.out | 5 +++-- src/test/regress/sql/copy2.sql | 3 +++ 2 files changed, 6 insertions(+), 2 deletions(-)
pgsql: Add some asserts based on LWLockHeldByMe() for replication slot
Add some asserts based on LWLockHeldByMe() for replication slot statistics Two assertions checking that ReplicationSlotAllocationLock is acquired are added to pgstat_create_replslot() and pgstat_drop_replslot(), corresponding to the routines in charge of the creation and the drop of replication slot statistics. The code previously relied on this assumption and documented it in comments, but did not enforce this policy at runtime. Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/ze_p-hmd_yfev...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/77cf6a78de9fa48976d8c9152a48290beb06dc8b Modified Files -- src/backend/utils/activity/pgstat_replslot.c | 4 1 file changed, 4 insertions(+)
pgsql: Keep replication slot statistics on invalidation
Keep replication slot statistics on invalidation The code path in charge of invalidating a replication slot includes a call to pgstat_drop_replslot(), which would result in removing the statistics of the slot once invalidated. However, there is no need to remove the statistics of an invalidated slot as one could still be interested in looking at them to understand the activity of the slot until its actual removal. The initial design of the feature committed in be87200efd used the approach to drop the slots, which is likely why the statistics were still removed during the invalidation. Another problem with this operation is that it was done without holding ReplicationSlotAllocationLock, leaving it unprotected on concurrent activity. This part is arguably a bug, but that's a limited problem in practice so no backpatch is done. In passing, this commit adds a test to check this behavior. The only remaining code path where slot statistics are dropped now related to the slot getting dropped. Author: Bertrand Drouvot Discussion: https://postgr.es/m/zermh08eq6yyd...@ip-10-97-1-34.eu-west-3.compute.internal Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d6e171fed6c56fc17405445951d5028b7c86a4e3 Modified Files -- src/backend/replication/slot.c | 1 - src/test/recovery/t/035_standby_logical_decoding.pl | 20 2 files changed, 20 insertions(+), 1 deletion(-)
pgsql: Use printf's %m format instead of strerror(errno) in more places
Use printf's %m format instead of strerror(errno) in more places Most callers of strerror() are removed from the backend code. The remaining callers require special handling with a saved errno from a previous system call. The frontend code still needs strerror() where error states need to be handled outside of fprintf. Note that pg_regress is not changed to use %m as the TAP output may clobber errno, since those functions call fprintf() and friends before evaluating the format string. Support for %m in src/port/snprintf.c has been added in d6c55de1f99a, hence all the stable branches currently supported include it. Author: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87sf13jhuw@wibble.ilmari.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2c8118ee5d980e11f73683fcda2329c323aa381e Modified Files -- src/backend/postmaster/postmaster.c | 21 +++-- src/backend/postmaster/syslogger.c | 2 +- src/backend/utils/misc/guc.c | 9 +-- src/bin/initdb/findtimezone.c| 4 +- src/bin/pg_ctl/pg_ctl.c | 74 +- src/bin/pg_dump/compress_gzip.c | 2 +- src/bin/pg_dump/compress_none.c | 5 +- src/bin/pg_upgrade/check.c | 41 -- src/bin/pg_upgrade/controldata.c | 6 +- src/bin/pg_upgrade/exec.c| 14 ++-- src/bin/pg_upgrade/file.c| 98 src/bin/pg_upgrade/function.c| 3 +- src/bin/pg_upgrade/option.c | 10 +-- src/bin/pg_upgrade/parallel.c| 12 +-- src/bin/pg_upgrade/pg_upgrade.c | 4 +- src/bin/pg_upgrade/relfilenumber.c | 5 +- src/bin/pg_upgrade/tablespace.c | 4 +- src/bin/pg_upgrade/version.c | 9 +-- src/common/psprintf.c| 4 +- src/interfaces/ecpg/preproc/ecpg.c | 12 +-- src/port/path.c | 3 +- src/test/isolation/isolationtester.c | 2 +- src/test/modules/libpq_pipeline/libpq_pipeline.c | 4 +- src/tools/ifaddrs/test_ifaddrs.c | 2 +- 24 files changed, 158 insertions(+), 192 deletions(-)
pgsql: Improve consistency of replication slot statistics
Improve consistency of replication slot statistics The replication slot stats stored in shared memory rely on an internal index number. Both pgstat_reset_replslot() and pgstat_fetch_replslot() lacked some LWLock protections with ReplicationSlotControlLock while operating on these index numbers. This issue could cause these two functions to potentially operate on incorrect slots when taken in isolation in the event of slots dropped and/or re-created concurrently. Note that pg_stat_get_replication_slot() is called once per slot when querying pg_stat_replication_slots, meaning that the stats are retrieved across multiple ReplicationSlotControlLock acquisitions. So, while this commit improves more consistency, it may still be possible that statistics are not completely consistent for a single scan of pg_stat_replication_slots under concurrent replication slot drop or creation activity. The issue should unlikely be a problem in practice, causing the report of inconsistent stats or or the stats reset of an incorrect slot, so no backpatch is done. Author: Bertrand Drouvot Reviewed-by: Heikki Linnakangas, Shveta Malik, Michael Paquier Discussion: https://postgr.es/m/zegq1hdwfflkj...@ip-10-97-1-34.eu-west-3.compute.internal Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b36fbd9f8da140f5b0ef9f7daa6b3cb4cae8a69b Modified Files -- src/backend/utils/activity/pgstat_replslot.c | 42 +--- 1 file changed, 25 insertions(+), 17 deletions(-)
pgsql: Add some checkpoint and redo LSNs to a couple of recovery errors
Add some checkpoint and redo LSNs to a couple of recovery errors Two FATALs and one PANIC gain details about the LSNs they fail at: - When restoring from a backup_label, the FATAL log generated when not finding the checkpoint record now reports its LSN. - When restoring from a backup_label, the FATAL log generated when not finding the redo record referenced by a checkpoint record now shows both the redo and checkpoint record LSNs. - When not restoring from a backup_label, the PANIC error generated when not finding the checkpoint record now reports its LSN. This information is useful when debugging corruption issues, and these LSNs may not show up in the logs depending on the level of logging configured in the backend. Author: David Steele Discussion: https://postgr.es/m/0e90da89-77ca-4ccf-872c-9626d755e...@pgmasters.net Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f500ba07fa9d00eaa2d26ea66401e62f950163ae Modified Files -- src/backend/access/transam/xlogrecovery.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-)
pgsql: Improve support for ExplainOneQuery() hook
Improve support for ExplainOneQuery() hook There is a hook called ExplainOneQuery_hook that gives modules the possibility to plug into this code path, but, like utility.c for utility statement execution, there is no corresponding "standard" routine in the case of EXPLAIN executed for one Query. This commit adds a new standard_ExplainOneQuery() in explain.c, which is able to run explain on a non-utility Query without calling its hook. Per the feedback received from a couple of hackers, this change gives the possibility to cut a few hundred lines of code in some of the popular out-of-core modules as these maintained a copy of ExplainOneQuery(), adding custom extra information at the beginning or the end of the EXPLAIN output. Author: Mats Kindahl Reviewed-by: Aleksander Alekseev, Jelte Fennema-Nio, Andrei Lepikhov Discussion: https://postgr.es/m/ca+14427v_b4eaoc_o-iyyucrdmsotfpuh9k-qbexffy1hyj...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a04ddd077e61096da660e1c2f205e0c8277f2dcd Modified Files -- src/backend/commands/explain.c | 106 +++-- src/include/commands/explain.h | 4 ++ 2 files changed, 63 insertions(+), 47 deletions(-)
pgsql: Document units of "timeout" in ConditionVariableTimedSleep()
Document units of "timeout" in ConditionVariableTimedSleep() The timeout is passed down to WaitLatch() as milliseconds. Author: Shveta Malik Discussion: https://postgr.es/m/CAJpy0uC=xibqd1wapgyyvoiytap6uljaakld867zzxqu9ty...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f160bf06f72ab242a8336eff108a1f4e69539b77 Modified Files -- src/backend/storage/lmgr/condition_variable.c | 2 ++ 1 file changed, 2 insertions(+)
pgsql: Add support for DEFAULT in ALTER TABLE .. SET ACCESS METHOD
Add support for DEFAULT in ALTER TABLE .. SET ACCESS METHOD This option can be used to switch a relation to use the access method set by default_table_access_method when running the command. This has come up when discussing the possibility to support setting pg_class.relam for partitioned tables (left out here as future work), while being useful on its own for relations with physical storage as these must have an access method set. Per suggestion from Justin Pryzby. Author: Michael Paquier Reviewed-by: Justin Pryzby Discussion: https://postgr.es/m/ZeCZ89xAVFeOmrQC@pryzbyj2023 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d61a6cad6418f643a5773352038d0dfe5d3535b8 Modified Files -- doc/src/sgml/ref/alter_table.sgml | 6 -- src/backend/commands/tablecmds.c| 4 +++- src/backend/parser/gram.y | 10 -- src/bin/psql/tab-complete.c | 3 ++- src/test/regress/expected/create_am.out | 23 +++ src/test/regress/sql/create_am.sql | 12 6 files changed, 52 insertions(+), 6 deletions(-)
pgsql: Update comment of AlterTableCmd->name in parsenodes.h
Update comment of AlterTableCmd->name in parsenodes.h Since b0483263dda0, this field can be used to store an access method name for ALTER TABLE, but access methods were not mentioned in the field's description. Issue noticed while working on the area. Discussion: https://postgr.es/m/zewkgctk6xias...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4f8c1e7aaf11c42fa658eeab9baef0a035e76fe2 Modified Files -- src/include/nodes/parsenodes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Revert "Add recovery TAP test for race condition with slot inval
Revert "Add recovery TAP test for race condition with slot invalidations" This reverts commit 08a52ab151ca, due to some sporadic instability in the test. Getting the test right should require some redesign with a second injection point, but let's revert it for now to avoid these issues in the CI as a lot of patches are under discussion in this last commit fest. Per buildfarm members hachi and gokiburi. Discussion: https://postgr.es/m/zekqqhcriqlvp...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/65db0cfb4c036b14520a22dba5a858185b713643 Modified Files -- src/backend/replication/slot.c | 9 -- .../recovery/t/035_standby_logical_decoding.pl | 116 + 2 files changed, 2 insertions(+), 123 deletions(-)
pgsql: Revert "Fix parallel-safety check of expressions and predicate f
Revert "Fix parallel-safety check of expressions and predicate for index builds" This reverts commit eae7be600be7, following a discussion with Tom Lane, due to concerns that this impacts the decisions made by the planner for the number of workers spawned based on the inlining and const-folding of index expressions and predicate for cases that would have worked until this commit. Discussion: https://postgr.es/m/162802.1709746...@sss.pgh.pa.us Backpatch-through: 12 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c46817ee512afa156561cce2dd6dc8440fe98d55 Modified Files -- src/backend/optimizer/plan/planner.c | 12 +- src/backend/utils/cache/lsyscache.c | 68 --- src/include/utils/lsyscache.h | 2 - src/test/regress/expected/btree_index.out | 19 - src/test/regress/sql/btree_index.sql | 22 -- 5 files changed, 2 insertions(+), 121 deletions(-)
pgsql: Revert "Fix parallel-safety check of expressions and predicate f
Revert "Fix parallel-safety check of expressions and predicate for index builds" This reverts commit eae7be600be7, following a discussion with Tom Lane, due to concerns that this impacts the decisions made by the planner for the number of workers spawned based on the inlining and const-folding of index expressions and predicate for cases that would have worked until this commit. Discussion: https://postgr.es/m/162802.1709746...@sss.pgh.pa.us Backpatch-through: 12 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/49b971298a9b4271a9d5f91dcc969c5cb1acfbc1 Modified Files -- src/backend/optimizer/plan/planner.c | 12 +- src/backend/utils/cache/lsyscache.c | 68 --- src/include/utils/lsyscache.h | 2 - src/test/regress/expected/btree_index.out | 19 - src/test/regress/sql/btree_index.sql | 22 -- 5 files changed, 2 insertions(+), 121 deletions(-)
pgsql: Revert "Fix parallel-safety check of expressions and predicate f
Revert "Fix parallel-safety check of expressions and predicate for index builds" This reverts commit eae7be600be7, following a discussion with Tom Lane, due to concerns that this impacts the decisions made by the planner for the number of workers spawned based on the inlining and const-folding of index expressions and predicate for cases that would have worked until this commit. Discussion: https://postgr.es/m/162802.1709746...@sss.pgh.pa.us Backpatch-through: 12 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e82b64a92cf5650e618b26b85ca5c0f090286bb4 Modified Files -- src/backend/optimizer/plan/planner.c | 12 +- src/backend/utils/cache/lsyscache.c | 68 --- src/include/utils/lsyscache.h | 2 - src/test/regress/expected/btree_index.out | 19 - src/test/regress/sql/btree_index.sql | 22 -- 5 files changed, 2 insertions(+), 121 deletions(-)
pgsql: Revert "Fix parallel-safety check of expressions and predicate f
Revert "Fix parallel-safety check of expressions and predicate for index builds" This reverts commit eae7be600be7, following a discussion with Tom Lane, due to concerns that this impacts the decisions made by the planner for the number of workers spawned based on the inlining and const-folding of index expressions and predicate for cases that would have worked until this commit. Discussion: https://postgr.es/m/162802.1709746...@sss.pgh.pa.us Backpatch-through: 12 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/69e8f9dadb01377b8b757aa892ef00ce377f047e Modified Files -- src/backend/optimizer/plan/planner.c | 12 +- src/backend/utils/cache/lsyscache.c | 68 --- src/include/utils/lsyscache.h | 2 - src/test/regress/expected/btree_index.out | 19 - src/test/regress/sql/btree_index.sql | 22 -- 5 files changed, 2 insertions(+), 121 deletions(-)
pgsql: Revert "Fix parallel-safety check of expressions and predicate f
Revert "Fix parallel-safety check of expressions and predicate for index builds" This reverts commit eae7be600be7, following a discussion with Tom Lane, due to concerns that this impacts the decisions made by the planner for the number of workers spawned based on the inlining and const-folding of index expressions and predicate for cases that would have worked until this commit. Discussion: https://postgr.es/m/162802.1709746...@sss.pgh.pa.us Backpatch-through: 12 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/70a31629aede159a99226da3edc4b1c10192cc44 Modified Files -- src/backend/optimizer/plan/planner.c | 12 +- src/backend/utils/cache/lsyscache.c | 68 --- src/include/utils/lsyscache.h | 2 - src/test/regress/expected/btree_index.out | 19 - src/test/regress/sql/btree_index.sql | 22 -- 5 files changed, 2 insertions(+), 121 deletions(-)
pgsql: Revert "Fix parallel-safety check of expressions and predicate f
Revert "Fix parallel-safety check of expressions and predicate for index builds" This reverts commit eae7be600be7, following a discussion with Tom Lane, due to concerns that this impacts the decisions made by the planner for the number of workers spawned based on the inlining and const-folding of index expressions and predicate for cases that would have worked until this commit. Discussion: https://postgr.es/m/162802.1709746...@sss.pgh.pa.us Backpatch-through: 12 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/099ca50bd41c1a72fe5a086bb095858ea74c88de Modified Files -- src/backend/optimizer/plan/planner.c | 12 +- src/backend/utils/cache/lsyscache.c | 68 --- src/include/utils/lsyscache.h | 2 - src/test/regress/expected/btree_index.out | 19 - src/test/regress/sql/btree_index.sql | 22 -- 5 files changed, 2 insertions(+), 121 deletions(-)
pgsql: Fix parallel-safety check of expressions and predicate for index
Fix parallel-safety check of expressions and predicate for index builds As coded, the planner logic that calculates the number of parallel workers to use for a parallel index build uses expressions and predicates from the relcache, which are flattened for the planner by eval_const_expressions(). As reported in the bug, an immutable parallel-unsafe function flattened in the relcache would become a Const, which would be considered as parallel-safe, even if the predicate or the expressions including the function are not safe in parallel workers. Depending on the expressions or predicate used, this could cause the parallel build to fail. Tests are included that check parallel index builds with parallel-unsafe predicate and expressions. Two routines are added to lsyscache.h to be able to retrieve expressions and predicate of an index from its pg_index data. Reported-by: Alexander Lakhin Author: Tender Wang Reviewed-by: Jian He, Michael Paquier Discussion: https://postgr.es/m/CAHewXN=UaAaNn9ruHDH3Os8kxLVmtWqbssnf=dZN_s9=evh...@mail.gmail.com Backpatch-through: 12 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4ec8f7708b6b4c494bd0ccd937fc28d34a872b49 Modified Files -- src/backend/optimizer/plan/planner.c | 12 +- src/backend/utils/cache/lsyscache.c | 68 +++ src/include/utils/lsyscache.h | 2 + src/test/regress/expected/btree_index.out | 19 + src/test/regress/sql/btree_index.sql | 22 ++ 5 files changed, 121 insertions(+), 2 deletions(-)
pgsql: Fix parallel-safety check of expressions and predicate for index
Fix parallel-safety check of expressions and predicate for index builds As coded, the planner logic that calculates the number of parallel workers to use for a parallel index build uses expressions and predicates from the relcache, which are flattened for the planner by eval_const_expressions(). As reported in the bug, an immutable parallel-unsafe function flattened in the relcache would become a Const, which would be considered as parallel-safe, even if the predicate or the expressions including the function are not safe in parallel workers. Depending on the expressions or predicate used, this could cause the parallel build to fail. Tests are included that check parallel index builds with parallel-unsafe predicate and expressions. Two routines are added to lsyscache.h to be able to retrieve expressions and predicate of an index from its pg_index data. Reported-by: Alexander Lakhin Author: Tender Wang Reviewed-by: Jian He, Michael Paquier Discussion: https://postgr.es/m/CAHewXN=UaAaNn9ruHDH3Os8kxLVmtWqbssnf=dZN_s9=evh...@mail.gmail.com Backpatch-through: 12 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/56a8ab2fc6f76ec2ca7a257f36ef8138a3fd473a Modified Files -- src/backend/optimizer/plan/planner.c | 12 +- src/backend/utils/cache/lsyscache.c | 68 +++ src/include/utils/lsyscache.h | 2 + src/test/regress/expected/btree_index.out | 19 + src/test/regress/sql/btree_index.sql | 22 ++ 5 files changed, 121 insertions(+), 2 deletions(-)
pgsql: Fix parallel-safety check of expressions and predicate for index
Fix parallel-safety check of expressions and predicate for index builds As coded, the planner logic that calculates the number of parallel workers to use for a parallel index build uses expressions and predicates from the relcache, which are flattened for the planner by eval_const_expressions(). As reported in the bug, an immutable parallel-unsafe function flattened in the relcache would become a Const, which would be considered as parallel-safe, even if the predicate or the expressions including the function are not safe in parallel workers. Depending on the expressions or predicate used, this could cause the parallel build to fail. Tests are included that check parallel index builds with parallel-unsafe predicate and expressions. Two routines are added to lsyscache.h to be able to retrieve expressions and predicate of an index from its pg_index data. Reported-by: Alexander Lakhin Author: Tender Wang Reviewed-by: Jian He, Michael Paquier Discussion: https://postgr.es/m/CAHewXN=UaAaNn9ruHDH3Os8kxLVmtWqbssnf=dZN_s9=evh...@mail.gmail.com Backpatch-through: 12 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c0e0174c216bedcd3cfeb6b0bb5eead50713c772 Modified Files -- src/backend/optimizer/plan/planner.c | 12 +- src/backend/utils/cache/lsyscache.c | 68 +++ src/include/utils/lsyscache.h | 2 + src/test/regress/expected/btree_index.out | 19 + src/test/regress/sql/btree_index.sql | 22 ++ 5 files changed, 121 insertions(+), 2 deletions(-)
pgsql: Fix parallel-safety check of expressions and predicate for index
Fix parallel-safety check of expressions and predicate for index builds As coded, the planner logic that calculates the number of parallel workers to use for a parallel index build uses expressions and predicates from the relcache, which are flattened for the planner by eval_const_expressions(). As reported in the bug, an immutable parallel-unsafe function flattened in the relcache would become a Const, which would be considered as parallel-safe, even if the predicate or the expressions including the function are not safe in parallel workers. Depending on the expressions or predicate used, this could cause the parallel build to fail. Tests are included that check parallel index builds with parallel-unsafe predicate and expressions. Two routines are added to lsyscache.h to be able to retrieve expressions and predicate of an index from its pg_index data. Reported-by: Alexander Lakhin Author: Tender Wang Reviewed-by: Jian He, Michael Paquier Discussion: https://postgr.es/m/CAHewXN=UaAaNn9ruHDH3Os8kxLVmtWqbssnf=dZN_s9=evh...@mail.gmail.com Backpatch-through: 12 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b60d71c202cde344e0b447c2bb301addf95fa3b5 Modified Files -- src/backend/optimizer/plan/planner.c | 12 +- src/backend/utils/cache/lsyscache.c | 68 +++ src/include/utils/lsyscache.h | 2 + src/test/regress/expected/btree_index.out | 19 + src/test/regress/sql/btree_index.sql | 22 ++ 5 files changed, 121 insertions(+), 2 deletions(-)
pgsql: Fix parallel-safety check of expressions and predicate for index
Fix parallel-safety check of expressions and predicate for index builds As coded, the planner logic that calculates the number of parallel workers to use for a parallel index build uses expressions and predicates from the relcache, which are flattened for the planner by eval_const_expressions(). As reported in the bug, an immutable parallel-unsafe function flattened in the relcache would become a Const, which would be considered as parallel-safe, even if the predicate or the expressions including the function are not safe in parallel workers. Depending on the expressions or predicate used, this could cause the parallel build to fail. Tests are included that check parallel index builds with parallel-unsafe predicate and expressions. Two routines are added to lsyscache.h to be able to retrieve expressions and predicate of an index from its pg_index data. Reported-by: Alexander Lakhin Author: Tender Wang Reviewed-by: Jian He, Michael Paquier Discussion: https://postgr.es/m/CAHewXN=UaAaNn9ruHDH3Os8kxLVmtWqbssnf=dZN_s9=evh...@mail.gmail.com Backpatch-through: 12 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/eae7be600be715b2f393b018fc4b98c5b89296da Modified Files -- src/backend/optimizer/plan/planner.c | 12 +- src/backend/utils/cache/lsyscache.c | 68 +++ src/include/utils/lsyscache.h | 2 + src/test/regress/expected/btree_index.out | 19 + src/test/regress/sql/btree_index.sql | 22 ++ 5 files changed, 121 insertions(+), 2 deletions(-)
pgsql: Fix parallel-safety check of expressions and predicate for index
Fix parallel-safety check of expressions and predicate for index builds As coded, the planner logic that calculates the number of parallel workers to use for a parallel index build uses expressions and predicates from the relcache, which are flattened for the planner by eval_const_expressions(). As reported in the bug, an immutable parallel-unsafe function flattened in the relcache would become a Const, which would be considered as parallel-safe, even if the predicate or the expressions including the function are not safe in parallel workers. Depending on the expressions or predicate used, this could cause the parallel build to fail. Tests are included that check parallel index builds with parallel-unsafe predicate and expressions. Two routines are added to lsyscache.h to be able to retrieve expressions and predicate of an index from its pg_index data. Reported-by: Alexander Lakhin Author: Tender Wang Reviewed-by: Jian He, Michael Paquier Discussion: https://postgr.es/m/CAHewXN=UaAaNn9ruHDH3Os8kxLVmtWqbssnf=dZN_s9=evh...@mail.gmail.com Backpatch-through: 12 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/50b5913a87c9c2d67330d82429f6dda61441d40c Modified Files -- src/backend/optimizer/plan/planner.c | 12 +- src/backend/utils/cache/lsyscache.c | 68 +++ src/include/utils/lsyscache.h | 2 + src/test/regress/expected/btree_index.out | 19 + src/test/regress/sql/btree_index.sql | 22 ++ 5 files changed, 121 insertions(+), 2 deletions(-)
pgsql: Add recovery TAP test for race condition with slot invalidations
Add recovery TAP test for race condition with slot invalidations This commit adds a recovery test to provide coverage for the bug fixed in 818fefd8fd, using an injection point to wait just after the process of an active slot is killed. The trick is to give enough time for effective_xmin and effective_catalog_xmin to advance so as the slot invalidation robustness can be checked since the active process is killed without holding its slot's mutex for a short time. Author: Bertrand Drouvot Discussion: https://postgr.es/m/zdyzya4yrnapw...@ip-10-97-1-34.eu-west-3.compute.internal Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/08a52ab151ca599406883768cdc08b7929e516de Modified Files -- src/backend/replication/slot.c | 9 ++ .../recovery/t/035_standby_logical_decoding.pl | 116 - 2 files changed, 123 insertions(+), 2 deletions(-)
pgsql: Add PostgreSQL::Test::Cluster::wait_for_event()
Add PostgreSQL::Test::Cluster::wait_for_event() Per a demand from the author and the reviewer of this commit, this adds to Cluster.pm a helper routine that can be used to monitor when a process reaches a wanted wait event. This can be used in combination with the module injection_points for the "wait" callback, though it is not limited to it as this monitors pg_stat_activity for a wait_event and a backend_type. Author: Bertrand Drouvot Reviewed-by: Andrey Borodin Discussion: https://postgr.es/m/zebb4rmpez06t...@ip-10-97-1-34.eu-west-3.compute.internal Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/eca2c1ea85eb22716f93339f4e7cec3145c25723 Modified Files -- src/test/perl/PostgreSQL/Test/Cluster.pm | 23 +++ src/test/recovery/t/041_checkpoint_at_promote.pl | 8 +--- 2 files changed, 24 insertions(+), 7 deletions(-)
pgsql: Add regression test for restart points during promotion
Add regression test for restart points during promotion This test serves as a way to demonstrate how to use the features introduced in 37b369dc67bc, while providing coverage for 7863ee4def65 that caused the startup process to throw "PANIC: could not locate a valid checkpoint record" when starting recovery. The test checks that a node is able to properly restart following a crash when a restart point was finishing across a promotion, with an injection point added in the middle of CreateRestartPoint() to stop the restartpoint in flight. Note that this test fails when 7863ee4def65 is reverted. Kyotaro Horiguchi is the original author of this test, that has been originally posted on the thread where 7863ee4def65 was discussed. I have just upgraded and polished it to rely on injection points, making it much cheaper to reproduce the failure. This test requires injection points to be enabled in the builds, hence meson and ./configure need an update to pass this knowledge down to the test. The name of the new injection point follows the same naming convention as 6a1ea02c491d. The Makefile's EXTRA_INSTALL of recovery TAP tests is updated to include modules/injection_points. Author: Kyotaro Horiguchi, Michael Paquier Reviewed-by: Andrey Borodin, Bertrand Drouvot Discussion: https://postgr.es/m/zdluxbk5hgpol...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6782709df81f6c68450172605907fa9ff2b7f2b1 Modified Files -- src/backend/access/transam/xlog.c| 7 + src/test/recovery/Makefile | 7 +- src/test/recovery/meson.build| 4 + src/test/recovery/t/041_checkpoint_at_promote.pl | 170 +++ 4 files changed, 187 insertions(+), 1 deletion(-)
pgsql: injection_points: Add wait and wakeup of processes
injection_points: Add wait and wakeup of processes This commit adds two features to the in-core module for injection points: - A new callback called "wait" that can be attached to an injection point to make it wait. - A new SQL function to update the shared state and broadcast the update using a condition variable. This function uses an input an injection point name. This offers the possibility to stop a process in flight and wake it up in a controlled manner, which is useful when implementing tests that aim to trigger scenarios for race conditions (some tests are planned for integration). The logic uses a set of counters with a condition variable to monitor and broadcast the changes. Up to 8 waits can be registered in a single run, which should be plenty enough. Waits can be monitored in pg_stat_activity, based on the injection point name which is registered in a custom wait event under the "Extension" category. The shared memory state used by the module is registered using the DSM registry, and is optional, so there is no need to load the module with shared_preload_libraries to be able to use these features. Author: Michael Paquier Reviewed-by: Andrey Borodin, Bertrand Drouvot Discussion: https://postgr.es/m/zdluxbk5hgpol...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/37b369dc67bc44a3aab5c07e2c0012475efd00f3 Modified Files -- .../injection_points/injection_points--1.0.sql | 10 ++ .../modules/injection_points/injection_points.c| 155 + src/tools/pgindent/typedefs.list | 1 + 3 files changed, 166 insertions(+)
pgsql: Simplify pg_enc2gettext_tbl[] with C99-designated initializer sy
Simplify pg_enc2gettext_tbl[] with C99-designated initializer syntax This commit switches pg_enc2gettext_tbl[] in encnames.c to use a C99-designated initializer syntax. pg_bind_textdomain_codeset() is simplified so as it is possible to do a direct lookup at the gettext() array with a value of the enum pg_enc rather than doing a loop through all its elements, as long as the encoding value provided by GetDatabaseEncoding() is in the correct range of supported encoding values. Note that PG_MULE_INTERNAL gains a value in the array, pointing to NULL. Author: Jelte Fennema-Nio Discussion: https://postgr.es/m/cageczqt3caubcccsznewccmmbcuyp7xnam60j3ybd6pn5kh...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/655dc310460c601d434d05339b7fa46ed97675b3 Modified Files -- src/backend/utils/mb/mbutils.c | 24 +-- src/common/encnames.c| 86 src/include/mb/pg_wchar.h| 11 ++--- src/tools/pgindent/typedefs.list | 1 - 4 files changed, 55 insertions(+), 67 deletions(-)
pgsql: Use C99-designated initializer syntax for arrays related to enco
Use C99-designated initializer syntax for arrays related to encodings This updates the following lookup arrays to use C99-designated initializer syntax, indexed based on the enum pg_enc: pg_enc2icu_tbl[] pg_enc2name_tbl[] pg_wchar_table[] This is more readable, and removes problems with ordering mistakes as this removes dependencies between the arrays and their lookup index in the enum pg_enc. So, adding new encodings becomes easier, even if this does not happen often. Author: Jelte Fennema-Nio Reviewed-by: Jian He, Japin Li Discussion: https://postgr.es/m/cageczqt3caubcccsznewccmmbcuyp7xnam60j3ybd6pn5kh...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ada87a4d95fc39dfb1214edf6653390314b6f0df Modified Files -- src/common/encnames.c | 155 +++--- src/common/wchar.c| 85 + src/include/mb/pg_wchar.h | 8 +-- 3 files changed, 122 insertions(+), 126 deletions(-)
Re: pgsql: Mop-up for AIX-ectomy: remove now-dead test code.
On Wed, Feb 28, 2024 at 07:34:25PM +, Tom Lane wrote: > Mop-up for AIX-ectomy: remove now-dead test code. > > Commit 0b16bb877 removed the test query added by commit 79b716cfb, > but not the C-language support function used by that query. I don't > see any plausible reason why we'd need that function again, so throw > it overboard too. crake is complaining in some upgrade paths: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake=2024-02-28%2021%3A27%3A04 Some adjustments in AdjustUpgrade::adjust_new_dumpfile should do it, I suppose. -- Michael signature.asc Description: PGP signature
pgsql: Remove last NULL element in config_group_names[]
Remove last NULL element in config_group_names[] This has not been needed since 9d77708d83ee where there was a loop to print all the possible GUC groups, relying on the last element to be NULL. Author: Japin Li Reviewed-By: Jelte Fennema-Nio Discussion: https://postgr.es/m/cageczqt3caubcccsznewccmmbcuyp7xnam60j3ybd6pn5kh...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/48920476b490544a3ee137da714424cd354bc2b6 Modified Files -- src/backend/utils/misc/guc_tables.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
pgsql: Use C99-designated initializer syntax for more arrays
Use C99-designated initializer syntax for more arrays This is in the same spirit as ef5e2e90859a, updating this time some arrays in parser.c, relpath.c, guc_tables.c and pg_dump_sort.c so as the order of their elements has no need to match the enum structures they are based on anymore. Author: Jelte Fennema-Nio Reviewed-by: Jian He, Japin Li Discussion: https://postgr.es/m/cageczqt3caubcccsznewccmmbcuyp7xnam60j3ybd6pn5kh...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/afd8ef39094b0dff9d1f2bfecb1d9fa056b85e19 Modified Files -- src/backend/parser/parser.c | 12 +-- src/backend/utils/misc/guc_tables.c | 187 ++-- src/bin/pg_dump/pg_dump_sort.c | 94 +- src/common/relpath.c| 8 +- 4 files changed, 128 insertions(+), 173 deletions(-)
pgsql: Remove unnecessary array object_classes[] in dependency.c
Remove unnecessary array object_classes[] in dependency.c object_classes[] provided unnecessary indirection between catalog OIDs and the enum ObjectClass when calling add_object_address(). This array has been originally introduced in 30ec31604d5 and was useful because not all relation OIDs were compile-time constants back then, which has not been the case for a long time now for all the elements of ObjectClass. This commit removes object_classes[], switching to the catalog OIDs when calling add_object_address(). This shaves some code while saving in maintenance because it was necessary to maintain the enum ObjectClass and the array in sync when adding new object types. Reported-by: Jeff Davis Author: Jelte Fennema-Nio Reviewed-by: Jian He, Michael Paquier Discussion: https://postgr.es/m/cageczqt3caubcccsznewccmmbcuyp7xnam60j3ybd6pn5kh...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ef5e2e90859a39efdd3a78e528c544b585295a78 Modified Files -- src/backend/catalog/dependency.c | 181 ++- src/include/catalog/dependency.h | 4 +- 2 files changed, 63 insertions(+), 122 deletions(-)
pgsql: Fix comment thinko in sequence.c
Fix comment thinko in sequence.c One comment mentioned indexes, but the relation opened should be sequences. Reported-by: Matthias van de Meent Discussion: https://postgr.es/m/CAEze2WiMGNG9XK3NSUen-5BARhCnP=u=fxnf8pvpl2qdkeo...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/17a3f79f812cf196063c4146d64c6479e974a5c5 Modified Files -- src/backend/access/sequence/sequence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Group more closely cache updates for backends in sequence.c
Group more closely cache updates for backends in sequence.c Information of sequences is cached for each backend for currval() and nextval(), and the update of some cached information was mixed in the middle of computations based on the other properties of a sequence, for the increment value in nextval() and the cached state when altering a sequence. Grouping them makes the code easier to follow and to refactor in the future, when splitting the computation and the SeqTable change parts. Note that the cached data is untouched between the areas where these cache updates are moved. Issue noticed while doing some refactoring of the sequence code. Author: Michael Paquier Reviewed-by: Tomas Vondra Discussion: https://postgr.es/m/zwlohtkas0uvv...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6e951bf98e2e0230ed95db2fafc244536bd7502f Modified Files -- src/backend/commands/sequence.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-)
pgsql: Introduce sequence_*() access functions
Introduce sequence_*() access functions
Similarly to tables and indexes, these functions are able to open
relations with a sequence relkind, which is useful to make a distinction
with the other relation kinds. Previously, commands/sequence.c used a
mix of table_{close,open}() and relation_{close,open}() routines when
manipulating sequence relations, so this clarifies the code.
A direct effect of this change is to align the error messages produced
when attempting DDLs for sequences on relations with an unexpected
relkind, like a table or an index with ALTER SEQUENCE, providing an
extra error detail about the relkind of the relation used in the DDL
query.
Author: Michael Paquier
Reviewed-by: Tomas Vondra
Discussion: https://postgr.es/m/zwlohtkas0uvv...@paquier.xyz
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/449e798c77ed9a03f8bb04e5d324d4e3cfbbae8e
Modified Files
--
src/backend/access/Makefile | 2 +-
src/backend/access/meson.build | 1 +
src/backend/access/sequence/Makefile| 17 +++
src/backend/access/sequence/meson.build | 5 +++
src/backend/access/sequence/sequence.c | 78 +
src/backend/commands/sequence.c | 31 ++---
src/include/access/sequence.h | 23 ++
src/test/regress/expected/sequence.out | 3 +-
8 files changed, 140 insertions(+), 20 deletions(-)
pgsql: Make GetSlotInvalidationCause() return RS_INVAL_NONE on unexpect
Make GetSlotInvalidationCause() return RS_INVAL_NONE on unexpected input 943f7ae1c869 has changed GetSlotInvalidationCause() so as it would return the last element of SlotInvalidationCauses[] when an incorrect conflict reason name is given by a caller, but this should return RS_INVAL_NONE in such cases, even if such a state should never be reached in practice. Per gripe from Peter Smith. Reviewed-by: Bharath Rupireddy Discussion: https://postgr.es/m/cahut+ptsrswxczpgksasvtjo+bxrvj3hwp5ges14bbl-g+h...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/efa70c15c742511195e2ee6f0aef94d0797daf80 Modified Files -- src/backend/replication/slot.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
pgsql: Speed up uuid_out() by not relying on a StringInfo
Speed up uuid_out() by not relying on a StringInfo Since the size of the string representation of an uuid is fixed, there is no benefit in using a StringInfo. This commit simplifies uuid_oud() to not rely on a StringInfo, where avoiding the overhead of the string manipulation makes the function substantially faster. A COPY TO on a relation with one UUID attribute can show up to a 40% speedup when the bottleneck is the COPY computation with uuid_out() showing up at the top of the profiles (numbered measure here, Laurenz has mentioned something closer to 20% faster runtimes), for example when the data is fully in shared buffers or the OS cache. Author: Laurenz Albe Reviewed-by: Andres Freund, Michael Paquier Description: https://postgr.es/m/679d5455cbbb0af667ccb753da51a475bae1eaed.ca...@cybertec.at Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/011d60c4352c5c48c0f1a185e8a12833c22a58db Modified Files -- src/backend/utils/adt/uuid.c | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-)
pgsql: Add lookup table for replication slot conflict reasons
Add lookup table for replication slot conflict reasons This commit switches the handling of the conflict cause strings for replication slots to use a table rather than being explicitly listed, using a C99-designated initializer syntax for the array elements. This makes the whole more readable while easing future maintenance with less areas to update when adding a new conflict reason. This is similar to 74a730631065, but the scale of the change is smaller as there are less conflict causes than LWLock builtin tranche names. Author: Bharath Rupireddy Reviewed-by: Jelte Fennema-Nio Discussion: https://postgr.es/m/calj2acuxsla91qgfrjswnks58kxb1c03mbuwkmzqqmoaklw...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/943f7ae1c8693cf3ea59d103aaf9590ea062fb9c Modified Files -- src/backend/replication/slot.c | 45 ++--- src/backend/replication/slotfuncs.c | 24 +--- src/include/replication/slot.h | 13 +-- 3 files changed, 43 insertions(+), 39 deletions(-)
pgsql: Add option force_initdb to PostgreSQL::Test::Cluster:init()
Add option force_initdb to PostgreSQL::Test::Cluster:init()
This option is useful to bypass the default behavior of init() which
would create the data folder of a new cluster by copying it from a
template previously initdb'd, if any. Copying the data folder is much
cheaper than running initdb, but some tests may want to force that. For
example, one scenario of pg_combinebackup updated in this commit needs a
different system ID for two nodes.
Previously, this could only be achieved by unsetting
$ENV{'INITDB_TEMPLATE'}, which could become a problem in complex node
setups by making tests less efficient.
Author: Amul Sul
Reviewed-by: Robert Haas, Michael Paquier
Discussion: https://postgr.es/m/zc1tx9llonlgu...@paquier.xyz
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/ff9e1e764fcce9a34467d614611a34d4d2a91b50
Modified Files
--
src/bin/pg_combinebackup/t/005_integrity.pl | 18 ++
src/test/perl/PostgreSQL/Test/Cluster.pm| 17 -
2 files changed, 18 insertions(+), 17 deletions(-)
pgsql: Fix race leading to incorrect conflict cause in InvalidatePossib
Fix race leading to incorrect conflict cause in InvalidatePossiblyObsoleteSlot() The invalidation of an active slot is done in two steps: - Termination of the backend holding it, if any. - Report that the slot is obsolete, with a conflict cause depending on the slot's data. This can be racy because between these two steps the slot mutex would be released while doing system calls, which means that the effective_xmin and effective_catalog_xmin could advance during that time, detecting a conflict cause different than the one originally wanted before the process owning a slot is terminated. Holding the mutex longer is not an option, so this commit changes the code to record the LSNs stored in the slot during the termination of the process owning the slot. Bonus thanks to Alexander Lakhin for the various tests and the analysis. Author: Bertrand Drouvot Reviewed-by: Michael Paquier, Bharath Rupireddy Discussion: https://postgr.es/m/zatjw2xh+tquc...@ip-10-97-1-34.eu-west-3.compute.internal Backpatch-through: 16 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/59cea09f03a56a40bce70a7461226c4d45740d02 Modified Files -- src/backend/replication/slot.c | 39 +-- 1 file changed, 33 insertions(+), 6 deletions(-)
pgsql: Fix race leading to incorrect conflict cause in InvalidatePossib
Fix race leading to incorrect conflict cause in InvalidatePossiblyObsoleteSlot() The invalidation of an active slot is done in two steps: - Termination of the backend holding it, if any. - Report that the slot is obsolete, with a conflict cause depending on the slot's data. This can be racy because between these two steps the slot mutex would be released while doing system calls, which means that the effective_xmin and effective_catalog_xmin could advance during that time, detecting a conflict cause different than the one originally wanted before the process owning a slot is terminated. Holding the mutex longer is not an option, so this commit changes the code to record the LSNs stored in the slot during the termination of the process owning the slot. Bonus thanks to Alexander Lakhin for the various tests and the analysis. Author: Bertrand Drouvot Reviewed-by: Michael Paquier, Bharath Rupireddy Discussion: https://postgr.es/m/zatjw2xh+tquc...@ip-10-97-1-34.eu-west-3.compute.internal Backpatch-through: 16 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/818fefd8fd4412d45eb542155cb2833a2b864acc Modified Files -- src/backend/replication/slot.c | 39 +-- 1 file changed, 33 insertions(+), 6 deletions(-)
pgsql: doc: Use system-username instead of system-user
doc: Use system-username instead of system-user This inconsistency has been introduced in efb6f4a4f9b6. Reported-by: Julien Rouhaud Author: Bertrand Drouvot Discussion: https://postgr.es/m/zdmwux1hpiebk...@ip-10-97-1-34.eu-west-3.compute.internal Backpatch-through: 16 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/01ec4d89b91ed4c0cad57b188b530b9e7980ccb5 Modified Files -- doc/src/sgml/client-auth.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
