pgsql: Fix partitionwise join with partially-redundant join clauses

2024-07-29 Thread Richard Guo
Fix partitionwise join with partially-redundant join clauses To determine if the two relations being joined can use partitionwise join, we need to verify the existence of equi-join conditions involving pairs of matching partition keys for all partition keys. Currently we do that by looking through

pgsql: Refactor the checks for parameterized partial paths

2024-07-29 Thread Richard Guo
Refactor the checks for parameterized partial paths Parameterized partial paths are not supported, and we have several checks in try_partial_xxx_path functions to enforce this. For a partial nestloop join path, we need to ensure that if the inner path is parameterized, the parameterization is ful

pgsql: Short-circuit sort_inner_and_outer if there are no mergejoin cla

2024-07-29 Thread Richard Guo
Short-circuit sort_inner_and_outer if there are no mergejoin clauses In sort_inner_and_outer, we create mergejoin join paths by explicitly sorting both relations on each possible ordering of the available mergejoin clauses. However, if there are no available mergejoin clauses, we can skip this pr

pgsql: Add more debugging information when failing to read pgstats file

2024-07-29 Thread Michael Paquier
Add more debugging information when failing to read pgstats files This is useful to know which part of a stats file is corrupted when reading it, adding to the server logs a WARNING with details about what could not be read before giving up with the remaining data in the file. Author: Michael Paq

pgsql: SQL/JSON: Fix casting for integer EXISTS columns in JSON_TABLE

2024-07-29 Thread Amit Langote
SQL/JSON: Fix casting for integer EXISTS columns in JSON_TABLE The current method of coercing the boolean result value of JsonPathExists() to the target type specified for an EXISTS column, which is to call the type's input function via json_populate_type(), leads to an error when the target type

pgsql: SQL/JSON: Some fixes to JsonBehavior expression casting

2024-07-29 Thread Amit Langote
SQL/JSON: Some fixes to JsonBehavior expression casting 1. Remove the special case handling when casting the JsonBehavior expressions to types with typmod, like 86d33987 did for the casting of SQL/JSON constructor functions. 2. Fix casting for fixed-length character and bit string types by

pgsql: SQL/JSON: Some fixes to JsonBehavior expression casting

2024-07-29 Thread Amit Langote
SQL/JSON: Some fixes to JsonBehavior expression casting 1. Remove the special case handling when casting the JsonBehavior expressions to types with typmod, like 86d33987 did for the casting of SQL/JSON constructor functions. 2. Fix casting for fixed-length character and bit string types by

pgsql: SQL/JSON: Fix casting for integer EXISTS columns in JSON_TABLE

2024-07-29 Thread Amit Langote
SQL/JSON: Fix casting for integer EXISTS columns in JSON_TABLE The current method of coercing the boolean result value of JsonPathExists() to the target type specified for an EXISTS column, which is to call the type's input function via json_populate_type(), leads to an error when the target type

pgsql: Do not return NULL from pg_newlocale_from_collation().

2024-07-29 Thread Jeff Davis
Do not return NULL from pg_newlocale_from_collation(). Previously, pg_newlocale_from_collation() returned NULL as a special case for the DEFAULT_COLLATION_OID if the provider was libc. In that case the behavior would depend on the last call to setlocale(). Now, consistent with the other providers

pgsql: Add accidentally omitted test to meson build file

2024-07-29 Thread Melanie Plageman
Add accidentally omitted test to meson build file 01e2b7f0fd02a44e introduced a test that vacuum correctly removes tuples older than OldestXmin. The same commit was backpatched on 14-16, but 16 is the only version with meson and the test was mistakenly left off of the recovery test meson build fil

pgsql: Use DELETE instead of UPDATE to speed up vacuum test

2024-07-29 Thread Melanie Plageman
Use DELETE instead of UPDATE to speed up vacuum test d42f60ccf07d89c introduced a test which generated dead tuples for vacuum with an UPDATE. The test only required enough dead TIDs for two rounds of index vacuuming. This can be accomplished with a DELETE instead of an UPDATE -- which generates ab

pgsql: Use DELETE instead of UPDATE to speed up vacuum test

2024-07-29 Thread Melanie Plageman
Use DELETE instead of UPDATE to speed up vacuum test e2e992820f104def introduced a test which generated dead tuples for vacuum with an UPDATE. The test only required enough dead TIDs for two rounds of index vacuuming. This can be accomplished with a DELETE instead of an UPDATE -- which generates a

pgsql: Use DELETE instead of UPDATE to speed up vacuum test

2024-07-29 Thread Melanie Plageman
Use DELETE instead of UPDATE to speed up vacuum test 01e2b7f0fd02a44e introduced a test which generated dead tuples for vacuum with an UPDATE. The test only required enough dead TIDs for two rounds of index vacuuming. This can be accomplished with a DELETE instead of an UPDATE -- which generates a

pgsql: Detach syslogger from shared memory

2024-07-29 Thread Heikki Linnakangas
Detach syslogger from shared memory Commit aafc05de1b removed the calls to detach from shared memory from syslogger startup. That was not intentional, so put them back. Author: Rui Zhao Reviewed-by: Aleksander Alekseev Backpatch-through: 17 Discussion: https://www.postgresql.org/message-id/11505

pgsql: Detach syslogger from shared memory

2024-07-29 Thread Heikki Linnakangas
Detach syslogger from shared memory Commit aafc05de1b removed the calls to detach from shared memory from syslogger startup. That was not intentional, so put them back. Author: Rui Zhao Reviewed-by: Aleksander Alekseev Backpatch-through: 17 Discussion: https://www.postgresql.org/message-id/11505

Re: pgsql: Fix double-release of spinlock

2024-07-29 Thread Tom Lane
Andres Freund writes: > On 2024-07-29 12:45:19 -0400, Tom Lane wrote: >> Hmm, but how? > ... > I.e. the version using 2 as the locked state uses a three byte instruction vs > a two byte instruction before. > *If* we are worried about this, we could > a) Change the representation only for assert e

Re: pgsql: Fix double-release of spinlock

2024-07-29 Thread Andres Freund
On 2024-07-29 12:45:19 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2024-07-29 12:33:13 -0400, Tom Lane wrote: > >> I dunno, is that the only extra check that the --disable-spinlocks > >> implementation is providing? > > > I think it also provides the (valuable!) check that spinlocks were

pgsql: Remove dead generators for cyrillic encoding conversion tables

2024-07-29 Thread Heikki Linnakangas
Remove dead generators for cyrillic encoding conversion tables These tools were used to read the koi-iso.tab, koi-win.tab, and koi-alt.tab files, which contained the mappings between the single-byte cyrillic encodings. However, those data files were removed in commit 4c3c8c048d, back in 2003. Thes

Re: pgsql: Fix double-release of spinlock

2024-07-29 Thread Robert Haas
On Mon, Jul 29, 2024 at 12:40 PM Andres Freund wrote: > I think it also provides the (valuable!) check that spinlocks were actually > initialized. But that again seems like something we'd be better off adding > more general infrastructure for - nobody runs --disable-spinlocks locally, we > shouldn

Re: pgsql: Fix double-release of spinlock

2024-07-29 Thread Tom Lane
Andres Freund writes: > On 2024-07-29 12:33:13 -0400, Tom Lane wrote: >> I dunno, is that the only extra check that the --disable-spinlocks >> implementation is providing? > I think it also provides the (valuable!) check that spinlocks were actually > initialized. But that again seems like someth

Re: pgsql: Fix double-release of spinlock

2024-07-29 Thread Andres Freund
Hi, On 2024-07-29 12:33:13 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2024-07-29 11:31:56 -0400, Tom Lane wrote: > >> There was some recent discussion about getting rid of > >> --disable-spinlocks on the grounds that nobody would use > >> hardware that lacked native spinlocks. But now

pgsql: Remove tab completion for CREATE UNLOGGED MATERIALIZED VIEW.

2024-07-29 Thread Nathan Bossart
Remove tab completion for CREATE UNLOGGED MATERIALIZED VIEW. Commit 3bf3ab8c56 added support for unlogged materialized views, but commit 3223b25ff7 reverted that feature before it made it into a release. However, the latter commit left the grammar and tab-completion support intact. This commit r

Re: pgsql: Fix double-release of spinlock

2024-07-29 Thread Tom Lane
Andres Freund writes: > On 2024-07-29 11:31:56 -0400, Tom Lane wrote: >> There was some recent discussion about getting rid of >> --disable-spinlocks on the grounds that nobody would use >> hardware that lacked native spinlocks. But now I wonder >> if there is a testing/debugging reason to keep i

Re: pgsql: Fix double-release of spinlock

2024-07-29 Thread Andres Freund
Hi, On 2024-07-29 11:31:56 -0400, Tom Lane wrote: > Heikki Linnakangas writes: > > Commit 9d9b9d46f3 added spinlocks to protect the fields in ProcSignal > > flags, but in EmitProcSignalBarrier(), the spinlock was released > > twice. With most spinlock implementations, releasing a lock that's not

pgsql: Reduce number of commands dumpTableSchema emits for binary upgra

2024-07-29 Thread Tom Lane
Reduce number of commands dumpTableSchema emits for binary upgrade. Avoid issuing a separate SQL UPDATE command for each column when directly manipulating pg_attribute contents in binary upgrade mode. With the separate updates, we triggered a relcache invalidation with each update. For a table wi

pgsql: Reduce number of commands dumpTableSchema emits for binary upgra

2024-07-29 Thread Tom Lane
Reduce number of commands dumpTableSchema emits for binary upgrade. Avoid issuing a separate SQL UPDATE command for each column when directly manipulating pg_attribute contents in binary upgrade mode. With the separate updates, we triggered a relcache invalidation with each update. For a table wi

pgsql: Count individual SQL commands in pg_restore's --transaction-size

2024-07-29 Thread Tom Lane
Count individual SQL commands in pg_restore's --transaction-size mode. The initial implementation in commit 959b38d77 counted one action per TOC entry (except for some special cases for multi-blob BLOBS entries). This assumes that TOC entries are all about equally complex, but it turns out that t

pgsql: Count individual SQL commands in pg_restore's --transaction-size

2024-07-29 Thread Tom Lane
Count individual SQL commands in pg_restore's --transaction-size mode. The initial implementation in commit 959b38d77 counted one action per TOC entry (except for some special cases for multi-blob BLOBS entries). This assumes that TOC entries are all about equally complex, but it turns out that t

Re: pgsql: Fix double-release of spinlock

2024-07-29 Thread Tom Lane
Heikki Linnakangas writes: > Commit 9d9b9d46f3 added spinlocks to protect the fields in ProcSignal > flags, but in EmitProcSignalBarrier(), the spinlock was released > twice. With most spinlock implementations, releasing a lock that's not > held is not easy to notice, because most of the time it d

Re: pgsql: Move cancel key generation to after forking the backend

2024-07-29 Thread Heikki Linnakangas
On 29/07/2024 17:30, Heikki Linnakangas wrote: On 29/07/2024 16:25, Heikki Linnakangas wrote: On 29/07/2024 16:23, Daniel Gustafsson wrote: On 29 Jul 2024, at 15:18, Heikki Linnakangas wrote: Move cancel key generation to after forking the backend longfin seems a tad sad about this one: pr

pgsql: Fix double-release of spinlock

2024-07-29 Thread Heikki Linnakangas
Fix double-release of spinlock Commit 9d9b9d46f3 added spinlocks to protect the fields in ProcSignal flags, but in EmitProcSignalBarrier(), the spinlock was released twice. With most spinlock implementations, releasing a lock that's not held is not easy to notice, because most of the time it does

Re: pgsql: Move cancel key generation to after forking the backend

2024-07-29 Thread Heikki Linnakangas
On 29/07/2024 16:25, Heikki Linnakangas wrote: On 29/07/2024 16:23, Daniel Gustafsson wrote: On 29 Jul 2024, at 15:18, Heikki Linnakangas wrote: Move cancel key generation to after forking the backend longfin seems a tad sad about this one: procsignal.c:87:3: error: redefinition of typedef

Re: pgsql: Move cancel key generation to after forking the backend

2024-07-29 Thread Heikki Linnakangas
On 29/07/2024 16:23, Daniel Gustafsson wrote: On 29 Jul 2024, at 15:18, Heikki Linnakangas wrote: Move cancel key generation to after forking the backend longfin seems a tad sad about this one: procsignal.c:87:3: error: redefinition of typedef 'ProcSignalHeader' is a C11 feature [-Werror,-W

pgsql: Fix compiler warning/error about typedef redefinitions

2024-07-29 Thread Heikki Linnakangas
Fix compiler warning/error about typedef redefinitions Per buildfarm member 'sifaka': procsignal.c:87:3: error: redefinition of typedef 'ProcSignalHeader' is a C11 feature [-Werror,-Wtypedef-redefinition] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8bda213

Re: pgsql: Move cancel key generation to after forking the backend

2024-07-29 Thread Daniel Gustafsson
> On 29 Jul 2024, at 15:18, Heikki Linnakangas > wrote: > > Move cancel key generation to after forking the backend longfin seems a tad sad about this one: procsignal.c:87:3: error: redefinition of typedef 'ProcSignalHeader' is a C11 feature [-Werror,-Wtypedef-redefinition] } ProcSignalHeader

pgsql: Move cancel key generation to after forking the backend

2024-07-29 Thread Heikki Linnakangas
Move cancel key generation to after forking the backend Move responsibility of generating the cancel key to the backend process. The cancel key is now generated after forking, and the backend advertises it in the ProcSignal array. When a cancel request arrives, the backend handling it scans the Pr

pgsql: Fix outdated comment in smgrtruncate()

2024-07-29 Thread Heikki Linnakangas
Fix outdated comment in smgrtruncate() Commit c5315f4f44 replaced smgr_fsm_nblocks and smgr_vm_nblocks with smgr_cached_nblocks, but forgot to update this comment. Author: Kirill Reshke Discussion: https://www.postgresql.org/message-id/caldssph9va6sdsvjrcmspeyramf%2brfisk7gqjo1dtrnd3vd...@mail.g