pgsql: Fix the Drop Database hang.
Fix the Drop Database hang. The drop database command waits for the logical replication sync worker to accept ProcSignalBarrier and the worker's slot creation waits for the drop database to finish which leads to a deadlock. This happens because the tablesync worker holds interrupts while creating a slot. We prevent cancel/die interrupts while creating a slot in the table sync worker because it is possible that before the server finishes this command, a concurrent drop subscription happens which would complete without removing this slot and that leads to the slot existing until the end of walsender. However, the slot will eventually get dropped at the walsender exit time, so there is no danger of the dangling slot. This patch reallows cancel/die interrupts while creating a slot and modifies the test to wait for slots to become zero to prevent finding an ephemeral slot. The reported hang doesn't happen in PG14 as the drop database starts to wait for ProcSignalBarrier with PG15 (commits 4eb2176318 and e2f65f4255) but it is good to backpatch this till PG14 as it is not a good idea to prevent interrupts during a network call that could block indefinitely. Reported-by: Lakshmi Narayanan Sreethar Diagnosed-by: Andres Freund Author: Hou Zhijie Reviewed-by: Vignesh C, Amit Kapila Backpatch-through: 14, where it was introduced in commit 6b67d72b60 Discussion: https://postgr.es/m/CA+kvmZELXQ4ZD3U=xcxug3kvfgkupon1qrej8c-rmrodrlo...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6c6d6ba3ee2c160b53f727cf8e612014b316d6e4 Modified Files -- src/backend/replication/logical/tablesync.c | 7 --- src/test/subscription/t/004_sync.pl | 10 +++--- 2 files changed, 7 insertions(+), 10 deletions(-)
pgsql: Fix the Drop Database hang.
Fix the Drop Database hang. The drop database command waits for the logical replication sync worker to accept ProcSignalBarrier and the worker's slot creation waits for the drop database to finish which leads to a deadlock. This happens because the tablesync worker holds interrupts while creating a slot. We prevent cancel/die interrupts while creating a slot in the table sync worker because it is possible that before the server finishes this command, a concurrent drop subscription happens which would complete without removing this slot and that leads to the slot existing until the end of walsender. However, the slot will eventually get dropped at the walsender exit time, so there is no danger of the dangling slot. This patch reallows cancel/die interrupts while creating a slot and modifies the test to wait for slots to become zero to prevent finding an ephemeral slot. The reported hang doesn't happen in PG14 as the drop database starts to wait for ProcSignalBarrier with PG15 (commits 4eb2176318 and e2f65f4255) but it is good to backpatch this till PG14 as it is not a good idea to prevent interrupts during a network call that could block indefinitely. Reported-by: Lakshmi Narayanan Sreethar Diagnosed-by: Andres Freund Author: Hou Zhijie Reviewed-by: Vignesh C, Amit Kapila Backpatch-through: 14, where it was introduced in commit 6b67d72b60 Discussion: https://postgr.es/m/CA+kvmZELXQ4ZD3U=xcxug3kvfgkupon1qrej8c-rmrodrlo...@mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fd270b728b28bd1a2973837498977de67d0a887e Modified Files -- src/backend/replication/logical/tablesync.c | 7 --- src/test/subscription/t/004_sync.pl | 10 +++--- 2 files changed, 7 insertions(+), 10 deletions(-)
pgsql: Fix the Drop Database hang.
Fix the Drop Database hang. The drop database command waits for the logical replication sync worker to accept ProcSignalBarrier and the worker's slot creation waits for the drop database to finish which leads to a deadlock. This happens because the tablesync worker holds interrupts while creating a slot. We prevent cancel/die interrupts while creating a slot in the table sync worker because it is possible that before the server finishes this command, a concurrent drop subscription happens which would complete without removing this slot and that leads to the slot existing until the end of walsender. However, the slot will eventually get dropped at the walsender exit time, so there is no danger of the dangling slot. This patch reallows cancel/die interrupts while creating a slot and modifies the test to wait for slots to become zero to prevent finding an ephemeral slot. The reported hang doesn't happen in PG14 as the drop database starts to wait for ProcSignalBarrier with PG15 (commits 4eb2176318 and e2f65f4255) but it is good to backpatch this till PG14 as it is not a good idea to prevent interrupts during a network call that could block indefinitely. Reported-by: Lakshmi Narayanan Sreethar Diagnosed-by: Andres Freund Author: Hou Zhijie Reviewed-by: Vignesh C, Amit Kapila Backpatch-through: 14, where it was introduced in commit 6b67d72b60 Discussion: https://postgr.es/m/CA+kvmZELXQ4ZD3U=xcxug3kvfgkupon1qrej8c-rmrodrlo...@mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/267135d01d79c63dfba7fe69dd3b40c125c49a6f Modified Files -- src/backend/replication/logical/tablesync.c | 7 --- src/test/subscription/t/004_sync.pl | 10 +++--- 2 files changed, 7 insertions(+), 10 deletions(-)
pgsql: dblink, postgres_fdw: Handle interrupts during connection establ
dblink, postgres_fdw: Handle interrupts during connection establishment Until now dblink and postgres_fdw did not process interrupts during connection establishment. Besides preventing query cancellations etc, this can lead to undetected deadlocks, as global barriers are not processed. These aforementioned undetected deadlocks are the reason for the spate of CI test failures in the FreeBSD 'test_running' step. Fix the bug by using the helper from libpq-be-fe-helpers.h, introduced in a prior commit. Besides fixing the bug, this also removes duplicated code around reserving file descriptors. As the change is relatively large and there are no field reports of the problem, don't backpatch for now. Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/20220925232237.p6uskba2dw6fn...@awork3.anarazel.de Backpatch: Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e4602483e95bebd4da31e4ea95dc5c7f715c1e4f Modified Files -- contrib/dblink/dblink.c | 79 ++- contrib/postgres_fdw/connection.c | 42 +++-- 2 files changed, 17 insertions(+), 104 deletions(-)
pgsql: Add helper library for use of libpq inside the server environmen
Add helper library for use of libpq inside the server environment Currently dblink and postgres_fdw don't process interrupts during connection establishment. Besides preventing query cancellations etc, this can lead to undetected deadlocks, as global barriers are not processed. Libpqwalreceiver in contrast, processes interrupts during connection establishment. The required code is not trivial, so duplicating it into additional places does not seem like a good option. These aforementioned undetected deadlocks are the reason for the spate of CI test failures in the FreeBSD 'test_running' step. For now the helper library is just a header, as it needs to be linked into each extension using libpq, and it seems too small to be worth adding a dedicated static library for. The conversion to the helper are done in subsequent commits. Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/20220925232237.p6uskba2dw6fn...@awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/28a591711d505f1f64c4f2eff5873ca2de0abede Modified Files -- src/include/libpq/libpq-be-fe-helpers.h | 242 1 file changed, 242 insertions(+)
pgsql: libpqwalreceiver: Convert to libpq-be-fe-helpers.h
libpqwalreceiver: Convert to libpq-be-fe-helpers.h In contrast to the changes to dblink and postgres_fdw, this does not fix a bug, as libpqwalreceiver did already process interrupts. Besides reducing code duplication, the conversion leads to libpqwalreceiver now using reserving file descriptors for libpq connections. While not strictly required for the use in walreceiver, we are also using libpqwalreceiver for logical replication, where it does seem more important. Even if we eventually decide to backpatch the prior commits, there'd be no need to backpatch this commit, due to not fixing an active bug. Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/20220925232237.p6uskba2dw6fn...@awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/728f86fec65537eade8d9e751961782ddb527934 Modified Files -- .../libpqwalreceiver/libpqwalreceiver.c| 53 +++--- 1 file changed, 7 insertions(+), 46 deletions(-)
pgsql: Fix error handling in libpqrcv_connect()
Fix error handling in libpqrcv_connect() When libpqrcv_connect (also known as walrcv_connect()) failed, it leaked the libpq connection. In most paths that's fairly harmless, as the calling process will exit soon after. But e.g. CREATE SUBSCRIPTION could lead to a somewhat longer lived leak. Fix by releasing resources, including the libpq connection, on error. Add a test exercising the error code path. To make it reliable and safe, the test tries to connect to port=-1, which happens to fail during connection establishment, rather than during connection string parsing. Reviewed-by: Noah Misch Discussion: https://postgr.es/m/20230121011237.q52apbvlarfv6...@awork3.anarazel.de Backpatch: 11- Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/704a330a9ee882bebbe4abe44c9f174ceaaf2f69 Modified Files -- .../libpqwalreceiver/libpqwalreceiver.c| 26 +- src/test/regress/expected/subscription.out | 10 - src/test/regress/sql/subscription.sql | 9 +++- 3 files changed, 32 insertions(+), 13 deletions(-)
pgsql: Fix error handling in libpqrcv_connect()
Fix error handling in libpqrcv_connect() When libpqrcv_connect (also known as walrcv_connect()) failed, it leaked the libpq connection. In most paths that's fairly harmless, as the calling process will exit soon after. But e.g. CREATE SUBSCRIPTION could lead to a somewhat longer lived leak. Fix by releasing resources, including the libpq connection, on error. Add a test exercising the error code path. To make it reliable and safe, the test tries to connect to port=-1, which happens to fail during connection establishment, rather than during connection string parsing. Reviewed-by: Noah Misch Discussion: https://postgr.es/m/20230121011237.q52apbvlarfv6...@awork3.anarazel.de Backpatch: 11- Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/92fc1278786f3b135da19d11538e9d9b30f4b04a Modified Files -- .../libpqwalreceiver/libpqwalreceiver.c| 26 +- src/test/regress/expected/subscription.out | 10 - src/test/regress/sql/subscription.sql | 9 +++- 3 files changed, 32 insertions(+), 13 deletions(-)
pgsql: Fix error handling in libpqrcv_connect()
Fix error handling in libpqrcv_connect() When libpqrcv_connect (also known as walrcv_connect()) failed, it leaked the libpq connection. In most paths that's fairly harmless, as the calling process will exit soon after. But e.g. CREATE SUBSCRIPTION could lead to a somewhat longer lived leak. Fix by releasing resources, including the libpq connection, on error. Add a test exercising the error code path. To make it reliable and safe, the test tries to connect to port=-1, which happens to fail during connection establishment, rather than during connection string parsing. Reviewed-by: Noah Misch Discussion: https://postgr.es/m/20230121011237.q52apbvlarfv6...@awork3.anarazel.de Backpatch: 11- Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/243373159fb427dfb6fcf43e2ac403d9d3b82752 Modified Files -- .../libpqwalreceiver/libpqwalreceiver.c| 26 +- src/test/regress/expected/subscription.out | 10 - src/test/regress/sql/subscription.sql | 9 +++- 3 files changed, 32 insertions(+), 13 deletions(-)
pgsql: Fix error handling in libpqrcv_connect()
Fix error handling in libpqrcv_connect() When libpqrcv_connect (also known as walrcv_connect()) failed, it leaked the libpq connection. In most paths that's fairly harmless, as the calling process will exit soon after. But e.g. CREATE SUBSCRIPTION could lead to a somewhat longer lived leak. Fix by releasing resources, including the libpq connection, on error. Add a test exercising the error code path. To make it reliable and safe, the test tries to connect to port=-1, which happens to fail during connection establishment, rather than during connection string parsing. Reviewed-by: Noah Misch Discussion: https://postgr.es/m/20230121011237.q52apbvlarfv6...@awork3.anarazel.de Backpatch: 11- Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0a796b8b3e311ea21cf679bf71f39b42e859a686 Modified Files -- .../libpqwalreceiver/libpqwalreceiver.c| 26 +- src/test/regress/expected/subscription.out | 10 - src/test/regress/sql/subscription.sql | 9 +++- 3 files changed, 32 insertions(+), 13 deletions(-)
pgsql: Fix error handling in libpqrcv_connect()
Fix error handling in libpqrcv_connect() When libpqrcv_connect (also known as walrcv_connect()) failed, it leaked the libpq connection. In most paths that's fairly harmless, as the calling process will exit soon after. But e.g. CREATE SUBSCRIPTION could lead to a somewhat longer lived leak. Fix by releasing resources, including the libpq connection, on error. Add a test exercising the error code path. To make it reliable and safe, the test tries to connect to port=-1, which happens to fail during connection establishment, rather than during connection string parsing. Reviewed-by: Noah Misch Discussion: https://postgr.es/m/20230121011237.q52apbvlarfv6...@awork3.anarazel.de Backpatch: 11- Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bc54ef4ec25a3c642f1706a49f979b7750a2817e Modified Files -- .../libpqwalreceiver/libpqwalreceiver.c| 26 +- src/test/regress/expected/subscription.out | 10 - src/test/regress/sql/subscription.sql | 9 +++- 3 files changed, 32 insertions(+), 13 deletions(-)
pgsql: Fix error handling in libpqrcv_connect()
Fix error handling in libpqrcv_connect() When libpqrcv_connect (also known as walrcv_connect()) failed, it leaked the libpq connection. In most paths that's fairly harmless, as the calling process will exit soon after. But e.g. CREATE SUBSCRIPTION could lead to a somewhat longer lived leak. Fix by releasing resources, including the libpq connection, on error. Add a test exercising the error code path. To make it reliable and safe, the test tries to connect to port=-1, which happens to fail during connection establishment, rather than during connection string parsing. Reviewed-by: Noah Misch Discussion: https://postgr.es/m/20230121011237.q52apbvlarfv6...@awork3.anarazel.de Backpatch: 11- Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c5864805ba99f79b49b12dc14499da58b0e15eb8 Modified Files -- .../libpqwalreceiver/libpqwalreceiver.c| 26 +- src/test/regress/expected/subscription.out | 10 - src/test/regress/sql/subscription.sql | 9 +++- 3 files changed, 32 insertions(+), 13 deletions(-)
pgsql: Use OFFSET 0 instead of ORDER BY to stop subquery pullup
Use OFFSET 0 instead of ORDER BY to stop subquery pullup b762fed64 recently changed this test to prevent subquery pullup to allow us to test Memoize with lateral_vars. As pointed out by Tom Lane, OFFSET 0 is our standard way of preventing subquery pullups, so do it that way instead. Discussion: https://postgr.es/m/2144818.1674517...@sss.pgh.pa.us Backpatch-through: 14, same as b762fed64 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0765b2f8f6fe8b7c1c07f94b764ef8bb74a292b4 Modified Files -- src/test/regress/expected/memoize.out | 4 ++-- src/test/regress/sql/memoize.sql | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
pgsql: Use OFFSET 0 instead of ORDER BY to stop subquery pullup
Use OFFSET 0 instead of ORDER BY to stop subquery pullup b762fed64 recently changed this test to prevent subquery pullup to allow us to test Memoize with lateral_vars. As pointed out by Tom Lane, OFFSET 0 is our standard way of preventing subquery pullups, so do it that way instead. Discussion: https://postgr.es/m/2144818.1674517...@sss.pgh.pa.us Backpatch-through: 14, same as b762fed64 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5dc582da6b9a281321e687ae2b52f96b929d8d0e Modified Files -- src/test/regress/expected/memoize.out | 4 ++-- src/test/regress/sql/memoize.sql | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
pgsql: Use OFFSET 0 instead of ORDER BY to stop subquery pullup
Use OFFSET 0 instead of ORDER BY to stop subquery pullup b762fed64 recently changed this test to prevent subquery pullup to allow us to test Memoize with lateral_vars. As pointed out by Tom Lane, OFFSET 0 is our standard way of preventing subquery pullups, so do it that way instead. Discussion: https://postgr.es/m/2144818.1674517...@sss.pgh.pa.us Backpatch-through: 14, same as b762fed64 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9567686ec834e50ab10ae872a8394c9a9e590b0d Modified Files -- src/test/regress/expected/memoize.out | 4 ++-- src/test/regress/sql/memoize.sql | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
Re: pgsql: Fix LATERAL join test in test memoize.sql
David Rowley writes: > You're right that OFFSET 0 would have been a better choice. I just > wasn't aware that we were considering changing the code so we pull up > subqueries with an ORDER BY. No such plan is in the offing AFAIK, but it doesn't seem entirely out of the question either. > In fact, I thought there were several > good reasons we're not doing that. e.g. allow aggregation in outer > query by some order specified by the subquery. But perhaps any changes > we make in this area would be more conditional than just ignoring the > fact that the subquery has an ORDER BY. Yeah, we've historically honored subquery ORDER BY and I doubt we'd want to stop. But I'm not sure that that that completely precludes subquery flattening, especially for single-relation subqueries such as these. You could imagine, for example, still doing the pull-up and then only accepting paths for the rel that satisfy the ORDER BY. This could still lead to better optimization of the outer query than what happens now, I think. Anyway, it's not something I expect to happen soon, but maybe someday. regards, tom lane
Re: pgsql: Fix LATERAL join test in test memoize.sql
On Tue, 24 Jan 2023 at 12:37, Tom Lane wrote: > Hmmm ... we have an agreed syntax for a subquery optimization fence, > and that ain't it. I wouldn't count on this not breaking again in > the future. Why not OFFSET 0, which is the usual method? You're right that OFFSET 0 would have been a better choice. I just wasn't aware that we were considering changing the code so we pull up subqueries with an ORDER BY. In fact, I thought there were several good reasons we're not doing that. e.g. allow aggregation in outer query by some order specified by the subquery. But perhaps any changes we make in this area would be more conditional than just ignoring the fact that the subquery has an ORDER BY. In any case, I agree that OFFSET 0 is a better choice, so I'll go and edit that. David
Re: pgsql: Fix LATERAL join test in test memoize.sql
David Rowley writes: > Here we add a simple ORDER BY to stop the planner from being able to > pullup the lateral subquery. Hmmm ... we have an agreed syntax for a subquery optimization fence, and that ain't it. I wouldn't count on this not breaking again in the future. Why not OFFSET 0, which is the usual method? regards, tom lane
pgsql: Fix LATERAL join test in test memoize.sql
Fix LATERAL join test in test memoize.sql The test in question was meant to be testing Memoize to ensure it worked correctly when the inner side of the join contained lateral vars, however, nothing in the lateral subquery stopped it from being pulled up into the main query, so the planner did that, and that meant no more lateral vars. Here we add a simple ORDER BY to stop the planner from being able to pullup the lateral subquery. Author: Richard Guo Discussion: https://postgr.es/m/CAMbWs4_LHJaN4L-tXpKMiPFnsCJWU1P8Xh59o0W7AA6UN99=c...@mail.gmail.com Backpatch-through: 14, where Memoize was added. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b762fed6481e722a022ac2bea02151e080c31fa6 Modified Files -- src/test/regress/expected/memoize.out | 8 +--- src/test/regress/sql/memoize.sql | 6 -- 2 files changed, 9 insertions(+), 5 deletions(-)
pgsql: Fix LATERAL join test in test memoize.sql
Fix LATERAL join test in test memoize.sql The test in question was meant to be testing Memoize to ensure it worked correctly when the inner side of the join contained lateral vars, however, nothing in the lateral subquery stopped it from being pulled up into the main query, so the planner did that, and that meant no more lateral vars. Here we add a simple ORDER BY to stop the planner from being able to pullup the lateral subquery. Author: Richard Guo Discussion: https://postgr.es/m/CAMbWs4_LHJaN4L-tXpKMiPFnsCJWU1P8Xh59o0W7AA6UN99=c...@mail.gmail.com Backpatch-through: 14, where Memoize was added. Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/73f77ab508d1514ca604c47b6f56c5dee4dd9025 Modified Files -- src/test/regress/expected/memoize.out | 8 +--- src/test/regress/sql/memoize.sql | 6 -- 2 files changed, 9 insertions(+), 5 deletions(-)
pgsql: Fix LATERAL join test in test memoize.sql
Fix LATERAL join test in test memoize.sql The test in question was meant to be testing Memoize to ensure it worked correctly when the inner side of the join contained lateral vars, however, nothing in the lateral subquery stopped it from being pulled up into the main query, so the planner did that, and that meant no more lateral vars. Here we add a simple ORDER BY to stop the planner from being able to pullup the lateral subquery. Author: Richard Guo Discussion: https://postgr.es/m/CAMbWs4_LHJaN4L-tXpKMiPFnsCJWU1P8Xh59o0W7AA6UN99=c...@mail.gmail.com Backpatch-through: 14, where Memoize was added. Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bcec08907e9357425ec0b3ea9ce03fd41fa6b8de Modified Files -- src/test/regress/expected/memoize.out | 8 +--- src/test/regress/sql/memoize.sql | 6 -- 2 files changed, 9 insertions(+), 5 deletions(-)
pgsql: Fix XLogPageRead() comment
Fix XLogPageRead() comment 7fcbf6a and 2ff6555 changed the function signature of XLogPageRead() but did not update the comment. XLogReaderRoutine contains up to date information about the API, so no need to repeat all that at XLogPageRead(), but fix the mentions of the no longer existing function arguments. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8dd43894b1f5c0148dd36308fc607bfcc909e5bd Modified Files -- src/backend/access/transam/xlogrecovery.c | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-)
Re: pgsql: Remove special outfuncs/readfuncs handling of RangeVar.catalogna
po 23. 1. 2023 v 19:33 odesÃlatel Tom Lane napsal: > Remove special outfuncs/readfuncs handling of RangeVar.catalogname. > > Historically we skipped writing/reading this field, but that no > longer works under WRITE_READ_PARSE_PLAN_TREES since we expanded > the coverage of that option to include utility commands (787102b56). > Remove the special case and just treat this field normally. > > Bump catversion out of an abundance of caution --- I do not think > we currently ever store RangeVar nodes in the catalogs, but > perhaps I'm wrong. > > Per report from Pavel Stehule. > It helps Thank you Pavel > > Discussion: > https://postgr.es/m/cafj8prayvyu-qu7-nieqrryaqzk-yr3ujthq2lr62ps9m1d...@mail.gmail.com > > Branch > -- > master > > Details > --- > > https://git.postgresql.org/pg/commitdiff/3cece34be842178a3c5697a58e03fb4a5d576378 > > Modified Files > -- > src/include/catalog/catversion.h | 2 +- > src/include/nodes/primnodes.h| 7 ++- > 2 files changed, 3 insertions(+), 6 deletions(-) > >
pgsql: Add non-decimal integer support to type numeric.
Add non-decimal integer support to type numeric. This enhances the numeric type input function, adding support for hexadecimal, octal, and binary integers of any size, up to the limits of the numeric type. Since 6fcda9aba8, such non-decimal integers have been accepted by the parser as integer literals and passed through to numeric_in(). This commit gives numeric_in() the ability to handle them. While at it, simplify the handling of NaN and infinities, reducing the number of calls to pg_strncasecmp(), and arrange for pg_strncasecmp() to not be called at all for regular numbers. This gives a significant performance improvement for decimal inputs, more than offsetting the small performance hit of checking for non-decimal input. Discussion: https://postgr.es/m/CAEZATCV8XShnmT9HZy25C%2Bo78CVOFmUN5EM9FRAZ5xvYTggPMg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6dfacbf72b53b775e8442a7fd2fca7c24b139773 Modified Files -- src/backend/utils/adt/numeric.c | 360 +-- src/test/regress/expected/numeric.out| 78 +-- src/test/regress/expected/numerology.out | 48 +++-- src/test/regress/sql/numeric.sql | 14 ++ 4 files changed, 405 insertions(+), 95 deletions(-)
pgsql: Fix pgindent --show-diff option.
Fix pgindent --show-diff option. At least on my machine, the initial coding of this didn't actually work, because interpolation of "$post_fh->filename" doesn't act as intended. I threw in some double quotes too, just in case anybody tries to run this in a path containing spaces. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/62e1e28bf76910ffe47ddbc5c1fade41e1a65dac Modified Files -- src/tools/pgindent/pgindent | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Remove special outfuncs/readfuncs handling of RangeVar.catalogna
Remove special outfuncs/readfuncs handling of RangeVar.catalogname. Historically we skipped writing/reading this field, but that no longer works under WRITE_READ_PARSE_PLAN_TREES since we expanded the coverage of that option to include utility commands (787102b56). Remove the special case and just treat this field normally. Bump catversion out of an abundance of caution --- I do not think we currently ever store RangeVar nodes in the catalogs, but perhaps I'm wrong. Per report from Pavel Stehule. Discussion: https://postgr.es/m/cafj8prayvyu-qu7-nieqrryaqzk-yr3ujthq2lr62ps9m1d...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3cece34be842178a3c5697a58e03fb4a5d576378 Modified Files -- src/include/catalog/catversion.h | 2 +- src/include/nodes/primnodes.h| 7 ++- 2 files changed, 3 insertions(+), 6 deletions(-)
Re: pgsql: instr_time: Represent time as an int64 on all platforms
Hi, On 2023-01-23 01:55:19 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2023-01-23 01:20:54 -0500, Tom Lane wrote: > >> Yeah, there was some discussion about that already: > >> https://www.postgresql.org/message-id/20230121190303.7xjiwdg3gvb62...@awork3.anarazel.de > > > I was thinking of starting a starting a separate thread about it - it's > > mostly a plpython issue, the fact that my commit caused the compilation > > failure is somewhat random. > > True. It also seems odd to me that per your analysis, we fixed > the _POSIX_C_SOURCE conflict on 4 Aug 2011 and then broke it again > on 18 Dec 2011, yet nobody has noticed for nigh a dozen years --- > there has to be some other element in there. Well, we didn't *fully* break - all the system library headers included via postgres.h are still included first. It's "just" stuff like , that are included later / indirectly, where we broke it. It's not too hard to believe that changing _POSIX_C_SOURCE won't cause immediately visible problems oustide of a few headers that we already included via c.h. Greetings, Andres Freund
pgsql: Restructure Ldap TAP test
Restructure Ldap TAP test The code for detecting the Ldap installation and setting up a test server is broken out into a reusable module that can be used for additional tests to be added in later patches. Discussion: https://postgr.es/m/06005bfb-0fd7-9d08-e0e5-440f277b7...@dunslane.net Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ee4613d2b7327512477bcf8967e28a93fd01807d Modified Files -- src/test/ldap/LdapServer.pm | 320 src/test/ldap/t/001_auth.pl | 164 +++ 2 files changed, 340 insertions(+), 144 deletions(-)
pgsql: Add a test using ldapbindpasswd in pg_hba.conf
Add a test using ldapbindpasswd in pg_hba.conf This feature has not been covered in tests up to now. John Naylor and Andrew Dunstan Discussion: https://postgr.es/m/06005bfb-0fd7-9d08-e0e5-440f277b7...@dunslane.net Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a9dc7f9419e4f6cac419e195618dceac74846c83 Modified Files -- src/test/ldap/meson.build | 1 + src/test/ldap/t/002_bindpasswd.pl | 95 +++ 2 files changed, 96 insertions(+)
pgsql: Fix and clarify function comment on LogicalTapeSetCreate.
Fix and clarify function comment on LogicalTapeSetCreate. Commit c4649cce39 removed the "shared" and "ntapes" arguments, but the comment still talked about "shared". It also talked about "a shared file handle", which was technically correct because even before commit c4649cce39, the "shared file handle" referred to the "fileset" argument, not "shared". But it was very confusing. Improve the comment. Also add a comment on what the "preallocate" argument does. Backpatch to v15, just to make backpatching other patches easier in the future. Discussion: https://www.postgresql.org/message-id/af989685-91d5-aad4-8f60-1d066b5ec...@enterprisedb.com Reviewed-by: Peter Eisentraut Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/95f62b16a3344e48ecce1ceb2882e5af24c13a1b Modified Files -- src/backend/utils/sort/logtape.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-)
pgsql: Add non-destructive modes to pgindent
Add non-destructive modes to pgindent This adds two modes of running pgindent, neither of which results in any changes being made to the source code. The --show-diff option shows what changes would have been made, and the --silent-diff option just exits with a status of 2 if any changes would be made. The second of these is intended for scripting use in places such as git hooks. Along the way some code cleanup is done, and a --help option is also added. Reviewed by Tom Lane Discussion: https://postgr.es/m/c9c9fa6d-6de6-48c2-4f8b-0fbeef026...@dunslane.net Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b90f0b57474eac3980be8146f2e45f73a05c994f Modified Files -- src/tools/pgindent/pgindent | 98 ++--- src/tools/pgindent/pgindent.man | 7 +++ 2 files changed, 79 insertions(+), 26 deletions(-)
pgsql: Optimise numeric division for 3 and 4 base-NBASE digit divisors.
Optimise numeric division for 3 and 4 base-NBASE digit divisors. On platforms with 128-bit integer support, introduce a new function div_var_int64(), along the same lines as div_var_int() added in d1b307eef2 for divisors with 1 or 2 base-NBASE digits, and use it to speed up div_var() and div_var_fast() in a similar way when the divisor has 3 or 4 base-NBASE digits. This gives significant performance gains for divisors with 9-16 decimal digits. Joel Jacobson. Discussion: https://postgr.es/m/b7a5893d-af18-4c0b-8918-96de5f1bbf39%40app.fastmail.com https://postgr.es/m/CAEZATCXGm%3DDyTq%3DFrcOqC0gPMVveKUYTaD5KRRoajrUTiWxVMw%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0aa38db56bf459d04ed58c22f7c689c0ae14e977 Modified Files -- src/backend/utils/adt/numeric.c | 167 1 file changed, 167 insertions(+)
pgsql: Run pgindent on heapam.c
Run pgindent on heapam.c An upcoming patch by Melanie Plageman does some refactoring work in this area. Run pgindent on that file now before making any changes so that it's easier to maintain/evolve each of the individual patches doing the refactor work. Additionally, add a few new required typedefs to the list to make it easier to do future pgindent runs on this file during the refactor work. Discussion: https://postgr.es/m/caakru_ysonhksdyfcqjsktbsrd32dp-jjxmv7hl0bpd-z0t...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/009dbdea02d74c72db2d1a57d5299f94f91fa975 Modified Files -- src/backend/access/heap/heapam.c | 17 + src/tools/pgindent/typedefs.list | 3 +++ 2 files changed, 12 insertions(+), 8 deletions(-)
pgsql: Fix and clarify function comment on LogicalTapeSetCreate.
Fix and clarify function comment on LogicalTapeSetCreate. Commit c4649cce39 removed the "shared" and "ntapes" arguments, but the comment still talked about "shared". It also talked about "a shared file handle", which was technically correct because even before commit c4649cce39, the "shared file handle" referred to the "fileset" argument, not "shared". But it was very confusing. Improve the comment. Also add a comment on what the "preallocate" argument does. Backpatch to v15, just to make backpatching other patches easier in the future. Discussion: https://www.postgresql.org/message-id/af989685-91d5-aad4-8f60-1d066b5ec...@enterprisedb.com Reviewed-by: Peter Eisentraut Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/236f1ea84c4ca6a29d790fac4b48eba12a74443c Modified Files -- src/backend/utils/sort/logtape.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-)
pgsql: Harden new parallel string_agg/array_agg regression test
Harden new parallel string_agg/array_agg regression test Per buildfarm member mandrill, it seems that max_parallel_workers_per_gather may not always be set to the default value of 2 when the new test added in 16fd03e95 is executed. Here let's just explicitly set that to 2 so that the planner never opts to use more than that many parallel workers. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/67c5b8840fcad07eeecd9af517b9b1ff09a3cf8e Modified Files -- src/test/regress/expected/aggregates.out | 1 + src/test/regress/sql/aggregates.sql | 1 + 2 files changed, 2 insertions(+)
