pgsql: Fix the Drop Database hang.

2023-01-23 Thread Amit Kapila
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

pgsql: Fix the Drop Database hang.

2023-01-23 Thread Amit Kapila
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

pgsql: Fix the Drop Database hang.

2023-01-23 Thread Amit Kapila
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

pgsql: dblink, postgres_fdw: Handle interrupts during connection establ

2023-01-23 Thread Andres Freund
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

pgsql: Add helper library for use of libpq inside the server environmen

2023-01-23 Thread Andres Freund
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

pgsql: libpqwalreceiver: Convert to libpq-be-fe-helpers.h

2023-01-23 Thread Andres Freund
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

pgsql: Fix error handling in libpqrcv_connect()

2023-01-23 Thread Andres Freund
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

pgsql: Fix error handling in libpqrcv_connect()

2023-01-23 Thread Andres Freund
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

pgsql: Fix error handling in libpqrcv_connect()

2023-01-23 Thread Andres Freund
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

pgsql: Fix error handling in libpqrcv_connect()

2023-01-23 Thread Andres Freund
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

pgsql: Fix error handling in libpqrcv_connect()

2023-01-23 Thread Andres Freund
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

pgsql: Fix error handling in libpqrcv_connect()

2023-01-23 Thread Andres Freund
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

pgsql: Use OFFSET 0 instead of ORDER BY to stop subquery pullup

2023-01-23 Thread David Rowley
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:

pgsql: Use OFFSET 0 instead of ORDER BY to stop subquery pullup

2023-01-23 Thread David Rowley
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:

pgsql: Use OFFSET 0 instead of ORDER BY to stop subquery pullup

2023-01-23 Thread David Rowley
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:

Re: pgsql: Fix LATERAL join test in test memoize.sql

2023-01-23 Thread Tom Lane
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

Re: pgsql: Fix LATERAL join test in test memoize.sql

2023-01-23 Thread David Rowley
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

Re: pgsql: Fix LATERAL join test in test memoize.sql

2023-01-23 Thread Tom Lane
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

pgsql: Fix LATERAL join test in test memoize.sql

2023-01-23 Thread David Rowley
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

pgsql: Fix LATERAL join test in test memoize.sql

2023-01-23 Thread David Rowley
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

pgsql: Fix LATERAL join test in test memoize.sql

2023-01-23 Thread David Rowley
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

pgsql: Fix XLogPageRead() comment

2023-01-23 Thread Peter Eisentraut
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

Re: pgsql: Remove special outfuncs/readfuncs handling of RangeVar.catalogna

2023-01-23 Thread Pavel Stehule
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

pgsql: Add non-decimal integer support to type numeric.

2023-01-23 Thread Dean Rasheed
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

pgsql: Fix pgindent --show-diff option.

2023-01-23 Thread Tom Lane
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 --

pgsql: Remove special outfuncs/readfuncs handling of RangeVar.catalogna

2023-01-23 Thread Tom Lane
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

Re: pgsql: instr_time: Represent time as an int64 on all platforms

2023-01-23 Thread Andres Freund
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

pgsql: Restructure Ldap TAP test

2023-01-23 Thread Andrew Dunstan
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

pgsql: Add a test using ldapbindpasswd in pg_hba.conf

2023-01-23 Thread Andrew Dunstan
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 ---

pgsql: Fix and clarify function comment on LogicalTapeSetCreate.

2023-01-23 Thread Heikki Linnakangas
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

pgsql: Add non-destructive modes to pgindent

2023-01-23 Thread Andrew Dunstan
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

pgsql: Optimise numeric division for 3 and 4 base-NBASE digit divisors.

2023-01-23 Thread Dean Rasheed
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

pgsql: Run pgindent on heapam.c

2023-01-23 Thread David Rowley
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

pgsql: Fix and clarify function comment on LogicalTapeSetCreate.

2023-01-23 Thread Heikki Linnakangas
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

pgsql: Harden new parallel string_agg/array_agg regression test

2023-01-23 Thread David Rowley
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