pgsql: Doc: mention foreign keys can reference unique indexes

for transformFkeyCheckAttrs() also didn't mention unique indexes, so fix that too. In passing make that header comment reflect reality in the various other aspects where it deviated from it. Bug: 18295 Reported-by: Gilles PARC Author: Laurenz Albe, David Rowley Discussion: https://www.postgresql.org

pgsql: Doc: mention foreign keys can reference unique indexes

for transformFkeyCheckAttrs() also didn't mention unique indexes, so fix that too. In passing make that header comment reflect reality in the various other aspects where it deviated from it. Bug: 18295 Reported-by: Gilles PARC Author: Laurenz Albe, David Rowley Discussion: https://www.postgresql.org

pgsql: Attempt to fix newly added Memoize regression test

Attempt to fix newly added Memoize regression test Both drongo and fairywren seem not to like a new regression test added by 2cca95e17. These machines show a different number of actual rows in the EXPLAIN ANALYZE output. Since the number of actual rows is divided by the number of loops, I

pgsql: De-dupicate Memoize cache keys

duplicates.  This isn't a problem for correctness, all it means is that the cache lookups will be suboptimal due to having redundant work to do on every hash table lookup and insert. Here we adjust paraminfo_get_equal_hashops() to look for duplicates and ignore them when we find them. Author: David

pgsql: Improve NestLoopParam generation for lateral subqueries

der of operations so that we create NestLoopParam for the lateral references first before doing replace_nestloop_params(). replace_nestloop_params() will find and reuse the existing NestLoopParam in cases where the Var exists in both locations. Author: Richard Guo Reviewed-by: Tom Lane, David Row

pgsql: Add better handling of redundant IS [NOT] NULL quals

equivalence with the original query. Author: David Rowley, Richard Guo, Andy Fan Reviewed-by: Richard Guo, David Rowley Discussion: https://postgr.es/m/caaphdvqg6xzdhyrpz0zgocevsmo0d3vxa9dvhrztkfqo30w...@mail.gmail.com Discussion: https://postgr.es/m/17540-7aa1855ad5ec18b4%40postgresql.org Branch

pgsql: Re-disallow Memoize for parameterized nested loops with join fil

Re-disallow Memoize for parameterized nested loops with join filters This was previously fixed in 9e215378d but got broken again as a result of 2489d76c4. It seems that commit causes ppi_clauses to contain duplicate clauses and it's no longer safe to check the list_length of that list to

pgsql: Re-disallow Memoize for parameterized nested loops with join fil

Re-disallow Memoize for parameterized nested loops with join filters This was previously fixed in 9e215378d but got broken again as a result of 2489d76c4. It seems that commit causes ppi_clauses to contain duplicate clauses and it's no longer safe to check the list_length of that list to

pgsql: Fix broken Bitmapset optimization in DiscreteKnapsack()

Fix broken Bitmapset optimization in DiscreteKnapsack() Some code in DiscreteKnapsack() attempted to zero all words in a Bitmapset by performing bms_del_members() to delete all the members from itself before replacing those members with members from another set. When that code was written, this

pgsql: Fix REALLOCATE_BITMAPSETS code

r bms_join(). I also removed some low-value comments that were trying to convey information about "these operations" without mentioning which operations it was talking about. It seems better to document these things in the function header comment instead. Author: Richard Guo, David Rowle

pgsql: Fix use of incorrect TupleTableSlot in DISTINCT aggregates

Fix use of incorrect TupleTableSlot in DISTINCT aggregates 1349d2790 added code to allow DISTINCT and ORDER BY aggregates to work more efficiently by using presorted input. That commit added some code that made use of the AggState's tmpcontext and adjusted the ecxt_outertuple and ecxt_innertuple

pgsql: Fix use of incorrect TupleTableSlot in DISTINCT aggregates

Fix use of incorrect TupleTableSlot in DISTINCT aggregates 1349d2790 added code to allow DISTINCT and ORDER BY aggregates to work more efficiently by using presorted input. That commit added some code that made use of the AggState's tmpcontext and adjusted the ecxt_outertuple and ecxt_innertuple

pgsql: Verify that attribute counts match in ExecCopySlot

Verify that attribute counts match in ExecCopySlot tts_virtual_copyslot() contained an Assert that checked that the srcslot contained <= attributes than the dstslot. This seems to be backwards as if the srcslot contained fewer attributes then the dstslot could be left with stale Datum values

pgsql: Don't use bms_membership() in cases where we don't need to

Don't use bms_membership() in cases where we don't need to 00b41463c adjusted Bitmapset so that an empty set is always represented as NULL. This makes checking for empty sets far cheaper than it used to be. There were various places in the code where we'd call bms_membership() to handle the 3

pgsql: Ensure we use the correct spelling of "ensure"

Ensure we use the correct spelling of "ensure" We seem to have accidentally used "insure" in a few places. Correct that. Author: Peter Smith Discussion: https://postgr.es/m/CAHut+Pv0biqrhA3pMhu40aDsj343mTsD75khKnHsLqR8P04f=q...@mail.gmail.com Backpatch-through: 12, oldest supported version

pgsql: Ensure we use the correct spelling of "ensure"

Ensure we use the correct spelling of "ensure" We seem to have accidentally used "insure" in a few places. Correct that. Author: Peter Smith Discussion: https://postgr.es/m/CAHut+Pv0biqrhA3pMhu40aDsj343mTsD75khKnHsLqR8P04f=q...@mail.gmail.com Backpatch-through: 12, oldest supported version

pgsql: Ensure we use the correct spelling of "ensure"

Ensure we use the correct spelling of "ensure" We seem to have accidentally used "insure" in a few places. Correct that. Author: Peter Smith Discussion: https://postgr.es/m/CAHut+Pv0biqrhA3pMhu40aDsj343mTsD75khKnHsLqR8P04f=q...@mail.gmail.com Backpatch-through: 12, oldest supported version

pgsql: Ensure we use the correct spelling of "ensure"

Ensure we use the correct spelling of "ensure" We seem to have accidentally used "insure" in a few places. Correct that. Author: Peter Smith Discussion: https://postgr.es/m/CAHut+Pv0biqrhA3pMhu40aDsj343mTsD75khKnHsLqR8P04f=q...@mail.gmail.com Backpatch-through: 12, oldest supported version

pgsql: Ensure we use the correct spelling of "ensure"

Ensure we use the correct spelling of "ensure" We seem to have accidentally used "insure" in a few places. Correct that. Author: Peter Smith Discussion: https://postgr.es/m/CAHut+Pv0biqrhA3pMhu40aDsj343mTsD75khKnHsLqR8P04f=q...@mail.gmail.com Backpatch-through: 12, oldest supported version

pgsql: Ensure we use the correct spelling of "ensure"

Ensure we use the correct spelling of "ensure" We seem to have accidentally used "insure" in a few places. Correct that. Author: Peter Smith Discussion: https://postgr.es/m/CAHut+Pv0biqrhA3pMhu40aDsj343mTsD75khKnHsLqR8P04f=q...@mail.gmail.com Backpatch-through: 12, oldest supported version

pgsql: Make use of initReadOnlyStringInfo() in more places

Make use of initReadOnlyStringInfo() in more places f0efa5aec introduced the concept of "read-only" StringInfos which makes use of an existing, possibly not NUL terminated, buffer. Here we adjust two places that make use of StringInfos to receive data to avoid using appendBinaryStringInfo() in

pgsql: Try again to fix the MSVC build

Try again to fix the MSVC build My last attempt in 39c959ef2 mistakenly conditionally added the missing file based on some unrelated condition. Reported-by: Thomas Munro Discussion: https://postgr.es/m/CA+hUKGLovvAXim9Fytn=jxks9s=JhP5=8oyy0cbxgg-ggal...@mail.gmail.com Branch -- master

pgsql: Add missing unicode_category.c to MSVC build scripts

Add missing unicode_category.c to MSVC build scripts Fixes MSVC build failure introduced by a02b37fc0 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/39c959ef25bd9cdd966ee024ab14f8f4214bb276 Modified Files -- src/tools/msvc/Mkvcbuild.pm | 1 + 1 file

pgsql: Stabilize postgres_fdw tests on 32-bit machines

Stabilize postgres_fdw tests on 32-bit machines cac169d68 adjusted DEFAULT_FDW_TUPLE_COST and that seems to have caused a test to become unstable on 32-bit machines. 4b14e1871 tried to fix this as originally the plan was flipping between a Nested Loop and Hash Join. That commit forced the

pgsql: Attempt to stabilize postgres_fdw tests

Attempt to stabilize postgres_fdw tests cac169d68 adjusted DEFAULT_FDW_TUPLE_COST and that seems to have caused a test to become unstable on 32-bit machines. Try to make it stable again. Reported-by: Michael Paquier Discussion: https://postgr.es/m/zum2iha8x2lrg...@paquier.xyz Branch --

pgsql: Increase DEFAULT_FDW_TUPLE_COST from 0.01 to 0.2

Increase DEFAULT_FDW_TUPLE_COST from 0.01 to 0.2 0.01 was unrealistically low as it's the same as the default cpu_tuple_cost and 10x cheaper than the default parallel_tuple_cost. It's hard to imagine a situation where fetching a tuple from a foreign server would be cheaper than fetching one from

pgsql: Adjust the order of the prechecks in pgrowlocks()

Adjust the order of the prechecks in pgrowlocks() 4b8266415 added a precheck to pgrowlocks() to ensure the given object's pg_class.relam is HEAP_TABLE_AM_OID, however, that check was put before another check which was checking if the given object was a partitioned table. Since the pg_class.relam

pgsql: Adjust the order of the prechecks in pgrowlocks()

Adjust the order of the prechecks in pgrowlocks() 4b8266415 added a precheck to pgrowlocks() to ensure the given object's pg_class.relam is HEAP_TABLE_AM_OID, however, that check was put before another check which was checking if the given object was a partitioned table. Since the pg_class.relam

pgsql: Adjust the order of the prechecks in pgrowlocks()

Adjust the order of the prechecks in pgrowlocks() 4b8266415 added a precheck to pgrowlocks() to ensure the given object's pg_class.relam is HEAP_TABLE_AM_OID, however, that check was put before another check which was checking if the given object was a partitioned table. Since the pg_class.relam

pgsql: Adjust the order of the prechecks in pgrowlocks()

Adjust the order of the prechecks in pgrowlocks() 4b8266415 added a precheck to pgrowlocks() to ensure the given object's pg_class.relam is HEAP_TABLE_AM_OID, however, that check was put before another check which was checking if the given object was a partitioned table. Since the pg_class.relam

pgsql: Adjust the order of the prechecks in pgrowlocks()

Adjust the order of the prechecks in pgrowlocks() 4b8266415 added a precheck to pgrowlocks() to ensure the given object's pg_class.relam is HEAP_TABLE_AM_OID, however, that check was put before another check which was checking if the given object was a partitioned table. Since the pg_class.relam

pgsql: Adjust the order of the prechecks in pgrowlocks()

Adjust the order of the prechecks in pgrowlocks() 4b8266415 added a precheck to pgrowlocks() to ensure the given object's pg_class.relam is HEAP_TABLE_AM_OID, however, that check was put before another check which was checking if the given object was a partitioned table. Since the pg_class.relam

pgsql: Optimize various aggregate deserialization functions, take 2

queries. Author: David Rowley Discussion: https://postgr.es/m/CAApHDvr%3De-YOigriSHHm324a40HPqcUhSp6pWWgjz5WwegR%3DcQ%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0c882a298881056176a27ccc44c5c3bb7c8f308c Modified Files -- src/backend

Re: pgsql: Prevent duplicate RTEPermissionInfo for plain-inheritance parent

On Thu, 26 Oct 2023 at 15:59, Amit Langote wrote: > src/backend/optimizer/util/inherit.c | 9 ++--- Hi Amit, I'm getting an unused variable warning from this with non-assert builds: [697/1908] Compiling C object src/backend/postgres_lib.a.p/optimizer_util_inherit.c.o

pgsql: Introduce the concept of read-only StringInfos

a mention in the release notes that a UDT's receive function mustn't rely on the input StringInfo being NUL terminated. Author: David Rowley Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAApHDvorfO3iBZ%3DxpiZvp3uHtJVLyFaPBSvcAhAq2HPLnaNSwQ%40mail.gmail.com Branch -- master Details ---

Re: pgsql: Remove useless self-joins

On Wed, 25 Oct 2023 at 22:59, Alexander Korotkov wrote: > src/test/regress/sql/join.sql | 359 There seems to be a few EXPLAINs added here that didn't include costs off. David

pgsql: Add missing include dir and references to libpq for MSVC build

Add missing include dir and references to libpq for MSVC build 66d6086cb adjusted pg_regress to require this but forgot to adjust the Visual Studio build script. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/673a17e31202cc47a9309e9b0b9b5fbec36080d3 Modified

pgsql: Fix runtime partition pruning for HASH partitioned tables

Fix runtime partition pruning for HASH partitioned tables This could only affect HASH partitioned tables with at least 2 partition key columns. If partition pruning was delayed until execution and the query contained an IS NULL qual on one of the partitioned keys, and some subsequent partitioned

pgsql: Fix runtime partition pruning for HASH partitioned tables

Fix runtime partition pruning for HASH partitioned tables This could only affect HASH partitioned tables with at least 2 partition key columns. If partition pruning was delayed until execution and the query contained an IS NULL qual on one of the partitioned keys, and some subsequent partitioned

pgsql: Fix runtime partition pruning for HASH partitioned tables

Fix runtime partition pruning for HASH partitioned tables This could only affect HASH partitioned tables with at least 2 partition key columns. If partition pruning was delayed until execution and the query contained an IS NULL qual on one of the partitioned keys, and some subsequent partitioned

pgsql: Fix runtime partition pruning for HASH partitioned tables

Fix runtime partition pruning for HASH partitioned tables This could only affect HASH partitioned tables with at least 2 partition key columns. If partition pruning was delayed until execution and the query contained an IS NULL qual on one of the partitioned keys, and some subsequent partitioned

pgsql: Fix runtime partition pruning for HASH partitioned tables

Fix runtime partition pruning for HASH partitioned tables This could only affect HASH partitioned tables with at least 2 partition key columns. If partition pruning was delayed until execution and the query contained an IS NULL qual on one of the partitioned keys, and some subsequent partitioned

pgsql: Fix runtime partition pruning for HASH partitioned tables

Fix runtime partition pruning for HASH partitioned tables This could only affect HASH partitioned tables with at least 2 partition key columns. If partition pruning was delayed until execution and the query contained an IS NULL qual on one of the partitioned keys, and some subsequent partitioned

pgsql: Fix runtime partition pruning for HASH partitioned tables

Fix runtime partition pruning for HASH partitioned tables This could only affect HASH partitioned tables with at least 2 partition key columns. If partition pruning was delayed until execution and the query contained an IS NULL qual on one of the partitioned keys, and some subsequent partitioned

pgsql: Doc: fix grammatical errors for enable_partitionwise_aggregate

Doc: fix grammatical errors for enable_partitionwise_aggregate Author: Andrew Atkinson Reviewed-by: Ashutosh Bapat Discussion: https://postgr.es/m/CAG6XLEnC%3DEgq0YHRic2kWWDs4xwQnQ_kBA6qhhzAq1-pO_9Tfw%40mail.gmail.com Backpatch-through: 11, where enable_partitionwise_aggregate was added Branch

pgsql: Doc: fix grammatical errors for enable_partitionwise_aggregate

Doc: fix grammatical errors for enable_partitionwise_aggregate Author: Andrew Atkinson Reviewed-by: Ashutosh Bapat Discussion: https://postgr.es/m/CAG6XLEnC%3DEgq0YHRic2kWWDs4xwQnQ_kBA6qhhzAq1-pO_9Tfw%40mail.gmail.com Backpatch-through: 11, where enable_partitionwise_aggregate was added Branch

pgsql: Doc: fix grammatical errors for enable_partitionwise_aggregate

Doc: fix grammatical errors for enable_partitionwise_aggregate Author: Andrew Atkinson Reviewed-by: Ashutosh Bapat Discussion: https://postgr.es/m/CAG6XLEnC%3DEgq0YHRic2kWWDs4xwQnQ_kBA6qhhzAq1-pO_9Tfw%40mail.gmail.com Backpatch-through: 11, where enable_partitionwise_aggregate was added Branch

pgsql: Doc: fix grammatical errors for enable_partitionwise_aggregate

Doc: fix grammatical errors for enable_partitionwise_aggregate Author: Andrew Atkinson Reviewed-by: Ashutosh Bapat Discussion: https://postgr.es/m/CAG6XLEnC%3DEgq0YHRic2kWWDs4xwQnQ_kBA6qhhzAq1-pO_9Tfw%40mail.gmail.com Backpatch-through: 11, where enable_partitionwise_aggregate was added Branch

pgsql: Doc: fix grammatical errors for enable_partitionwise_aggregate

Doc: fix grammatical errors for enable_partitionwise_aggregate Author: Andrew Atkinson Reviewed-by: Ashutosh Bapat Discussion: https://postgr.es/m/CAG6XLEnC%3DEgq0YHRic2kWWDs4xwQnQ_kBA6qhhzAq1-pO_9Tfw%40mail.gmail.com Backpatch-through: 11, where enable_partitionwise_aggregate was added Branch

pgsql: Doc: fix grammatical errors for enable_partitionwise_aggregate

Doc: fix grammatical errors for enable_partitionwise_aggregate Author: Andrew Atkinson Reviewed-by: Ashutosh Bapat Discussion: https://postgr.es/m/CAG6XLEnC%3DEgq0YHRic2kWWDs4xwQnQ_kBA6qhhzAq1-pO_9Tfw%40mail.gmail.com Backpatch-through: 11, where enable_partitionwise_aggregate was added Branch

pgsql: Doc: fix grammatical errors for enable_partitionwise_aggregate

Doc: fix grammatical errors for enable_partitionwise_aggregate Author: Andrew Atkinson Reviewed-by: Ashutosh Bapat Discussion: https://postgr.es/m/CAG6XLEnC%3DEgq0YHRic2kWWDs4xwQnQ_kBA6qhhzAq1-pO_9Tfw%40mail.gmail.com Backpatch-through: 11, where enable_partitionwise_aggregate was added Branch

pgsql: Fix incorrect step generation in HASH partition pruning

Fix incorrect step generation in HASH partition pruning get_steps_using_prefix_recurse() incorrectly assumed that it could stop recursive processing of the 'prefix' list when cur_keyno was one before the step_lastkeyno. Since hash partition pruning can prune using IS NULL quals, and these IS

pgsql: Fix incorrect step generation in HASH partition pruning

Fix incorrect step generation in HASH partition pruning get_steps_using_prefix_recurse() incorrectly assumed that it could stop recursive processing of the 'prefix' list when cur_keyno was one before the step_lastkeyno. Since hash partition pruning can prune using IS NULL quals, and these IS

pgsql: Fix incorrect step generation in HASH partition pruning

Fix incorrect step generation in HASH partition pruning get_steps_using_prefix_recurse() incorrectly assumed that it could stop recursive processing of the 'prefix' list when cur_keyno was one before the step_lastkeyno. Since hash partition pruning can prune using IS NULL quals, and these IS

pgsql: Fix incorrect step generation in HASH partition pruning

Fix incorrect step generation in HASH partition pruning get_steps_using_prefix_recurse() incorrectly assumed that it could stop recursive processing of the 'prefix' list when cur_keyno was one before the step_lastkeyno. Since hash partition pruning can prune using IS NULL quals, and these IS

pgsql: Fix incorrect step generation in HASH partition pruning

Fix incorrect step generation in HASH partition pruning get_steps_using_prefix_recurse() incorrectly assumed that it could stop recursive processing of the 'prefix' list when cur_keyno was one before the step_lastkeyno. Since hash partition pruning can prune using IS NULL quals, and these IS

pgsql: Fix incorrect step generation in HASH partition pruning

Fix incorrect step generation in HASH partition pruning get_steps_using_prefix_recurse() incorrectly assumed that it could stop recursive processing of the 'prefix' list when cur_keyno was one before the step_lastkeyno. Since hash partition pruning can prune using IS NULL quals, and these IS

pgsql: Fix incorrect step generation in HASH partition pruning

Fix incorrect step generation in HASH partition pruning get_steps_using_prefix_recurse() incorrectly assumed that it could stop recursive processing of the 'prefix' list when cur_keyno was one before the step_lastkeyno. Since hash partition pruning can prune using IS NULL quals, and these IS

pgsql: Fix possible crash in add_paths_to_append_rel()

Fix possible crash in add_paths_to_append_rel() While working on a8a968a82, I failed to consider that cheapest_startup_path can be NULL when there is no non-parameterized path in the pathlist. This is well documented in set_cheapest(), I just failed to notice. Here we adjust the code to just

pgsql: Revert "Optimize various aggregate deserialization functions"

Revert "Optimize various aggregate deserialization functions" This reverts commit 608fd198def5390c3490bfe903730207dfd8eeb4. On 2nd thoughts, the StringInfo API requires that strings are NUL terminated and pointing directly to the data in a bytea Datum isn't NUL terminated. Discussion:

pgsql: Optimize various aggregate deserialization functions

Optimize various aggregate deserialization functions The serialized representation of an internal aggregate state is a bytea value. In each deserial function, in order to "receive" the bytea value we appended it onto a short-lived StringInfoData using appendBinaryStringInfo. This was a little

pgsql: Strip off ORDER BY/DISTINCT aggregate pathkeys in create_agg_pat

Strip off ORDER BY/DISTINCT aggregate pathkeys in create_agg_path 1349d2790 added code to adjust the PlannerInfo.group_pathkeys so that ORDER BY / DISTINCT aggregate functions could obtain pre-sorted inputs to allow faster execution. That commit forgot to adjust the pathkeys in

pgsql: Strip off ORDER BY/DISTINCT aggregate pathkeys in create_agg_pat

Strip off ORDER BY/DISTINCT aggregate pathkeys in create_agg_path 1349d2790 added code to adjust the PlannerInfo.group_pathkeys so that ORDER BY / DISTINCT aggregate functions could obtain pre-sorted inputs to allow faster execution. That commit forgot to adjust the pathkeys in

pgsql: Remove debug_print_rel and replace usages with pprint

Remove debug_print_rel and replace usages with pprint Going by c4a1933b4, b33ef397a and 05893712c (to name just a few), it seems that maintaining debug_print_rel() is often forgotten. In the case of c4a1933b4, it was several years before anyone noticed that a path type was not handled by

pgsql: Consider cheap startup paths in add_paths_to_append_rel

from each of the child relations when the append rel has "consider_startup" set. Author: Andy Fan, David Rowley Discussion: https://www.postgresql.org/message-id/CAKU4AWrXSkUV=Pt-gRxQT7EbfUeNssprGyNsB=5mjibfz6s...@mail.gmail.com Branch -- master Details --- https://git.postgre

pgsql: Fix memory leak in Memoize code

Fix memory leak in Memoize code Ensure we switch to the per-tuple memory context to prevent any memory leaks of detoasted Datums in MemoizeHash_hash() and MemoizeHash_equal(). Reported-by: Orlov Aleksej Author: Orlov Aleksej, David Rowley Discussion: https://postgr.es/m

pgsql: Fix memory leak in Memoize code

Fix memory leak in Memoize code Ensure we switch to the per-tuple memory context to prevent any memory leaks of detoasted Datums in MemoizeHash_hash() and MemoizeHash_equal(). Reported-by: Orlov Aleksej Author: Orlov Aleksej, David Rowley Discussion: https://postgr.es/m

pgsql: Fix memory leak in Memoize code

Fix memory leak in Memoize code Ensure we switch to the per-tuple memory context to prevent any memory leaks of detoasted Datums in MemoizeHash_hash() and MemoizeHash_equal(). Reported-by: Orlov Aleksej Author: Orlov Aleksej, David Rowley Discussion: https://postgr.es/m

pgsql: Fix memory leak in Memoize code

Fix memory leak in Memoize code Ensure we switch to the per-tuple memory context to prevent any memory leaks of detoasted Datums in MemoizeHash_hash() and MemoizeHash_equal(). Reported-by: Orlov Aleksej Author: Orlov Aleksej, David Rowley Discussion: https://postgr.es/m

pgsql: Tidy-up some appendStringInfo*() usages

Tidy-up some appendStringInfo*() usages Make a few newish calls to appendStringInfo() which have no special formatting use appendStringInfoString() instead. Also, adjust usages of appendStringInfoString() which only append a string containing a single character to make use of

pgsql: Robustify find_base_rel and find_base_rel_ignore_join

and still fall through and raise an ERROR. Author: Ranier Vilela Reviewed-by: Ashutosh Bapat, David Rowley Discussion: https://postgr.es/m/CAEudQArQSghBu2gLojg4o_tnHj_x2HcS%3D%2BwewL3NJS8z0VnK%2Bg%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/

pgsql: Add missing TidRangePath handling in print_path()

Add missing TidRangePath handling in print_path() Tid Range scans were added back in bb437f995. That commit forgot to add handling for TidRangePaths in print_path(). Only people building with OPTIMIZER_DEBUG might have noticed this, which likely is the reason it's taken 4 years for anyone to

pgsql: Add missing TidRangePath handling in print_path()

Add missing TidRangePath handling in print_path() Tid Range scans were added back in bb437f995. That commit forgot to add handling for TidRangePaths in print_path(). Only people building with OPTIMIZER_DEBUG might have noticed this, which likely is the reason it's taken 4 years for anyone to

pgsql: Add missing TidRangePath handling in print_path()

Add missing TidRangePath handling in print_path() Tid Range scans were added back in bb437f995. That commit forgot to add handling for TidRangePaths in print_path(). Only people building with OPTIMIZER_DEBUG might have noticed this, which likely is the reason it's taken 4 years for anyone to

pgsql: Add missing TidRangePath handling in print_path()

Add missing TidRangePath handling in print_path() Tid Range scans were added back in bb437f995. That commit forgot to add handling for TidRangePaths in print_path(). Only people building with OPTIMIZER_DEBUG might have noticed this, which likely is the reason it's taken 4 years for anyone to

pgsql: Fix vacuumdb to pass buffer-usage-limit with analyze-only mode

could become this lack of escaping as VACUUM cannot be specified in a multi-command string. Reported-by: Ryoga Yoshida Author: Ryoga Yoshida, David Rowley Discussion: https://postgr.es/m/08930c0b541700a5264e5fbf3a685f5a%40oss.nttdata.com Backpatch-through: 16, where ae78cae3b was introduced. Branch

pgsql: Fix vacuumdb to pass buffer-usage-limit with analyze-only mode

could become this lack of escaping as VACUUM cannot be specified in a multi-command string. Reported-by: Ryoga Yoshida Author: Ryoga Yoshida, David Rowley Discussion: https://postgr.es/m/08930c0b541700a5264e5fbf3a685f5a%40oss.nttdata.com Backpatch-through: 16, where ae78cae3b was introduced. Branch

pgsql: Fix incorrect logic in plan dependency recording

Fix incorrect logic in plan dependency recording Both 50e17ad28 and 29f45e299 mistakenly tried to record a plan dependency on a function but mistakenly inverted the OidIsValid test. This meant that we'd record a dependency only when the function's Oid was InvalidOid. Clearly this was meant to

pgsql: Fix incorrect logic in plan dependency recording

Fix incorrect logic in plan dependency recording Both 50e17ad28 and 29f45e299 mistakenly tried to record a plan dependency on a function but mistakenly inverted the OidIsValid test. This meant that we'd record a dependency only when the function's Oid was InvalidOid. Clearly this was meant to

pgsql: Fix incorrect logic in plan dependency recording

Fix incorrect logic in plan dependency recording Both 50e17ad28 and 29f45e299 mistakenly tried to record a plan dependency on a function but mistakenly inverted the OidIsValid test. This meant that we'd record a dependency only when the function's Oid was InvalidOid. Clearly this was meant to

pgsql: Fix incorrect logic in plan dependency recording

Fix incorrect logic in plan dependency recording Both 50e17ad28 and 29f45e299 mistakenly tried to record a plan dependency on a function but mistakenly inverted the OidIsValid test. This meant that we'd record a dependency only when the function's Oid was InvalidOid. Clearly this was meant to

pgsql: Meson: check for pg_config_paths.h left over from make

Meson: check for pg_config_paths.h left over from make The meson build scripts attempt to find files left over from configure and fail, mentioning that "make maintainer-clean" should be run to remove these. This seems to have been done for files generated from configure. pg_config_paths.h is

pgsql: Meson: check for pg_config_paths.h left over from make

Meson: check for pg_config_paths.h left over from make The meson build scripts attempt to find files left over from configure and fail, mentioning that "make maintainer-clean" should be run to remove these. This seems to have been done for files generated from configure. pg_config_paths.h is

Re: pgsql: Add to_bin() and to_oct().

On Thu, 24 Aug 2023 at 02:50, Nathan Bossart wrote: > > Add to_bin() and to_oct(). src/include/catalog/pg_proc.dat | 12 + Did this maybe miss a catversion bump? David

Re: pgsql: Don't Memoize lateral joins with volatile join conditions

On Tue, 8 Aug 2023 at 10:06, Tom Lane wrote: > > David Rowley writes: > > * https://wiki.postgresql.org/wiki/Committing_checklist > > I thought we had something written down there after the last > discussion of this point, but maybe it was hanging fire because > we

Re: pgsql: Don't Memoize lateral joins with volatile join conditions

On Tue, 8 Aug 2023 at 01:02, Tom Lane wrote: > > David Rowley writes: > > Don't Memoize lateral joins with volatile join conditions > > Is this really something to be pushing into stable branches less than > 12 hours before a release wrap? We don't normally take such

pgsql: Don't Memoize lateral joins with volatile join conditions

Don't Memoize lateral joins with volatile join conditions The use of Memoize was already disabled in normal joins when the join conditions had volatile functions per the code in match_opclause_to_indexcol(). Ordinarily, the parameterization for the inner side of a nested loop will be an Index

pgsql: Don't Memoize lateral joins with volatile join conditions

Don't Memoize lateral joins with volatile join conditions The use of Memoize was already disabled in normal joins when the join conditions had volatile functions per the code in match_opclause_to_indexcol(). Ordinarily, the parameterization for the inner side of a nested loop will be an Index

pgsql: Don't Memoize lateral joins with volatile join conditions

Don't Memoize lateral joins with volatile join conditions The use of Memoize was already disabled in normal joins when the join conditions had volatile functions per the code in match_opclause_to_indexcol(). Ordinarily, the parameterization for the inner side of a nested loop will be an Index

pgsql: Don't Memoize lateral joins with volatile join conditions

Don't Memoize lateral joins with volatile join conditions The use of Memoize was already disabled in normal joins when the join conditions had volatile functions per the code in match_opclause_to_indexcol(). Ordinarily, the parameterization for the inner side of a nested loop will be an Index

pgsql: Fix misleading comment in paraminfo_get_equal_hashops

Fix misleading comment in paraminfo_get_equal_hashops The comment mistakenly claimed the code was checking PlaceHolderVars for volatile functions when the code was actually checking lateral vars. Update the comment to reflect the reality of the code. Author: Richard Guo Discussion:

pgsql: Tidy up join_search_one_level code

of for_each_from(). Ever since 1cff1b95a, Lists are arrays under the hood. lnext() and list_head() both seem a little too linked-list like. Author: Alex Hsieh, David Rowley, Richard Guo Reviewed-by: Julien Rouhaud Discussion: https://postgr.es/m/CANWNU8x9P9aCXGF%3DaT-A_8mLTAT0LkcZ_ySYrGbcuHzMQw2-1g

pgsql: Attempt to stabilize new window agg regression test

Attempt to stabilize new window agg regression test This test was recently added in 3900a02c9. It appears to be unstable in regards to the join order presumably due to the relations at either side of the join being equal in side. Here we add a qual to make one of them smaller so the planner is

pgsql: Minor adjustments to WindowAgg startup cost code

Minor adjustments to WindowAgg startup cost code This is a follow-on of 3900a02c9 containing some changes which I forgot to commit locally before forming a patch with git format-patch. Discussion: https://postgr.es/m/caaphdvrb0s5bmv+0-wttqwfe-bj0nowqtndu9qqfjz2vspl...@mail.gmail.com Branch

pgsql: Account for startup rows when costing WindowAggs

Palmer Author: David Rowley Reviewed-by: Andy Fan Discussion: https://postgr.es/m/17862-1ab8f74b0f7b0...@postgresql.org Discussion: https://postgr.es/m/caaphdvrb0s5bmv+0-wttqwfe-bj0nowqtndu9qqfjz2vspl...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff

pgsql: Fix performance regression in pg_strtointNN_safe functions

, octal and binary formats along with underscore separators are now supported. Author: Andres Freund, David Rowley Reported-by: Masahiko Sawada Reviewed-by: Dean Rasheed, John Naylor Discussion: https://postgr.es/m/CAD21AoDvDmUQeJtZrau1ovnT_smN940%3DKp6mszNGK3bq9yRN6g%40mail.gmail.com Backpatch-through

pgsql: Fix performance regression in pg_strtointNN_safe functions

, octal and binary formats along with underscore separators are now supported. Author: Andres Freund, David Rowley Reported-by: Masahiko Sawada Reviewed-by: Dean Rasheed, John Naylor Discussion: https://postgr.es/m/CAD21AoDvDmUQeJtZrau1ovnT_smN940%3DKp6mszNGK3bq9yRN6g%40mail.gmail.com Backpatch-through

pgsql: Fix overly strict Assert in jsonpath code

Fix overly strict Assert in jsonpath code This was failing for queries which try to get the .type() of a jpiLikeRegex. For example: select jsonb_path_query('["string", "string"]', '($[0] like_regex ".{7}").type()'); Reported-by: Alexander Kozhemyakin Bug: #18035

pgsql: Fix overly strict Assert in jsonpath code

Fix overly strict Assert in jsonpath code This was failing for queries which try to get the .type() of a jpiLikeRegex. For example: select jsonb_path_query('["string", "string"]', '($[0] like_regex ".{7}").type()'); Reported-by: Alexander Kozhemyakin Bug: #18035

pgsql: Fix overly strict Assert in jsonpath code

Fix overly strict Assert in jsonpath code This was failing for queries which try to get the .type() of a jpiLikeRegex. For example: select jsonb_path_query('["string", "string"]', '($[0] like_regex ".{7}").type()'); Reported-by: Alexander Kozhemyakin Bug: #18035

<    1   2   3   4   5   6   7   8   >