Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: d611f8b
Choose a base ref
...
head repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 923210e
Choose a head ref
  • 4 commits
  • 16 files changed
  • 2 contributors

Commits on Mar 7, 2025

  1. Explicitly pass snapshot necessary for omit_detached logic 

    This commit changes find_inheritance_children_extended() and
RelationBuildPartitionDesc() to accept the snapshot necessary
to implement the omit_detach logic correctly.

Previously, these functions used ActiveSnapshot to check if a
detach-pending partition's pg_inherits row was visible. This
logic aimed to make RI queries over partitioned PK tables under
REPEATABLE READ isolation handle detach-pending partitions
correctly. However, forcing a snapshot onto ActiveSnapshot led
to isolation violations by making scans in the query see changes
not consistent with the parent transaction's snapshot. A test
added in commit 00cb86e demonstrates this issue.

The new interface of RelationBuildPartitionDesc() and relevant
callers allows passing the necessary snapshot explcitly, thus
avoiding modifications to ActiveSnapshot. Default behavior remains
unchanged when no snapshot is provided, maintaining compatibility
with non-RI queries and other uses of
find_inheritance_children_extended().

A future commit will update RI PK lookups to use this interface.

Robert Haas contributed the changes to PartitionDesc interface.

Co-author: Robert Haas
Reviewed-by: Robert Haas
Discussion: https://postgr.es/m/CA+HiwqGkfJfYdeq5vHPh6eqPKjSbfpDDY+j-kXYFePQedtSLeg@mail.gmail.com
Discussion: https://postgr.es/m/CA+HiwqG5e8pk8s7+7zhr1Nc_PGyhEdM5f=pHkMOdK1RYWXfJsg@mail.gmail.com
    @amitlan
    amitlan authored and Commitfest Bot committed Mar 7, 2025
    Configuration menu
    Copy the full SHA
    7c8bd58 View commit details
    Browse the repository at this point in the history

  2. Avoid using SPI in RI trigger functions 

    Currently, ri_PlanCheck() uses SPI_prepare() to create an SPI plan
containing a CachedPlanSource for the SQL query used in RI checks.
Similarly, ri_PerformCheck() calls SPI_execute_snapshot() to
execute the query with a specific snapshot.

This commit introduces ri_PlanCreate() and ri_PlanExecute() to
replace SPI_prepare() and SPI_execute_snapshot(), respectively.

* ri_PlanCreate()

Creates an "RI plan" for a query using a caller-specified callback
function, such as ri_SqlStringPlanCreate(), which produces a
CachedPlanSource for the input SQL string. This mirrors SPI_prepare()
functionality.

* ri_PlanExecute()

Executes an "RI plan" using a callback saved within the "RI plan"
(struct RIPlan). For example, ri_SqlStringPlanExecute() fetches a
CachedPlan from the CachedPlanSource and executes its PlannedStmt
using the executor. Snapshot handling is now fully managed by
ri_PerformCheck(), eliminating dependence on SPI's snapshot logic.

These changes make ri_PlanCreate() and ri_PlanExecute() pluggable,
laying the groundwork for future commits to replace SQL-based RI
checks with optimized C functions for direct table/index scans.

Note:

This only addresses RI_* functions addressed from RI triggers and
not those called from tablecmds.c, such as RI_Initial_Check() and
RI_PartitionRemove_Check(), which still use SPI_prepare() and
SPI_execute_snapshot().

Reviewed-by: Robert Haas
Discussion: https://postgr.es/m/CA+HiwqGkfJfYdeq5vHPh6eqPKjSbfpDDY+j-kXYFePQedtSLeg@mail.gmail.com
Discussion: https://postgr.es/m/CA+HiwqG5e8pk8s7+7zhr1Nc_PGyhEdM5f=pHkMOdK1RYWXfJsg@mail.gmail.com
    @amitlan
    amitlan authored and Commitfest Bot committed Mar 7, 2025
    Configuration menu
    Copy the full SHA
    704f32d View commit details
    Browse the repository at this point in the history

  3. Avoid using an SQL query for some RI checks 

    For RI triggers that check whether a referenced value exists in the
referenced relation, it is sufficient to scan the foreign key
constraint's unique index directly, instead of issuing an SQL query.
This optimization improves the performance of these checks by nearly
40%, especially for bulk inserts.

This commit builds on the RIPlan infrastructure introduced in the
previous commit. It replaces ri_SqlStringPlanCreate() in
RI_FKey_check() and ri_Check_Pk_Match() with
ri_LookupKeyInPkRelPlanCreate(), which installs
ri_LookupKeyInPkRel() as the plan to implement these checks.
ri_LookupKeyInPkRel() contains logic to directly scan the unique key
index associated with the foreign key constraint.

Additionally, ri_LookupKeyInPkRel() explicitly passes LatestSnapshot
as omit_detached_snapshot to CreatePartitionDirectory(), avoiding
the reliance on setting ActiveSnapshot. The previous approach caused
primary key lookups on partitioned tables to return incorrect results
under REPEATABLE READ isolation level, as demonstrated by a test case
added in commit 00cb86e. This issue has now been fixed, and the
buggy output in src/test/isolation/expected/fk-snapshot.out has been
updated to reflect the correct behavior.

Lastly, this commit introduces an isolation test suite to verify
foreign key insertions under concurrent updates to referenced values.

Reviewed-by: Robert Haas
Discussion: https://postgr.es/m/CA+HiwqGkfJfYdeq5vHPh6eqPKjSbfpDDY+j-kXYFePQedtSLeg@mail.gmail.com
Discussion: https://postgr.es/m/CA+HiwqG5e8pk8s7+7zhr1Nc_PGyhEdM5f=pHkMOdK1RYWXfJsg@mail.gmail.com
    @amitlan
    amitlan authored and Commitfest Bot committed Mar 7, 2025
    Configuration menu
    Copy the full SHA
    ab1b2ac View commit details
    Browse the repository at this point in the history

  4. [CF 5450] v1 - Eliminating SPI / SQL from some RI trigger functions 

    This branch was automatically generated by a robot using patches from an
email thread registered at:

https://commitfest.postgresql.org/patch/5450

The branch will be overwritten each time a new patch version is posted to
the thread, and also periodically to check for bitrot caused by changes
on the master branch.

Patch(es): https://www.postgresql.org/message-id/CA+HiwqF4C0ws3cO+z5cLkPuvwnAwkSp7sfvgGj3yQ=Li6KNMqA@mail.gmail.com
Author(s): Amit Langote
    Commitfest Bot committed Mar 7, 2025
    Configuration menu
    Copy the full SHA
    923210e View commit details
    Browse the repository at this point in the history
Loading