postgresql.git/src/include/executor, branch master

Add slot-based table AM index scan interface.

2026-09-15T15:19:13Z

Add table_index_getnext_slot, a new table AM interface that serves as the single entry point for both plain and index-only index scans that use amgettuple. The table AM's index_scan_begin callback resolves which implementation the scan will use and stores it in an IndexScanDesc function pointer (xs_getnext_slot), which table_index_getnext_slot dispatches through. The interface intentionally avoids using fixed TableAmRoutine members, allowing the table AM to dynamically register an implementation based on conditions known at the start of each scan. That way a table AM can provide specialized variants that help the compiler produce more efficient code. heapam provides two implementations: one for plain index scans, and one for index-only scans. An upcoming commit that adds the amgetbatch interface will add two more. (Table AMs can opt to provide a single generic implementation, or to provide many specialized implementations, as requirements dictate.) heapam's xs_getnext_slot implementations make aggressive use of forced inlining to ensure that plain and index-only code paths are fully specialized at compile time, without duplicating the code they have in common. This specialization is necessary to keep icache and iTLB pressure to a minimum. The new interface moves visibility map checks required by index-only scans out of the executor (and selfuncs.c) and into heapam, enabling batching of visibility map lookups (though for now we continue to just perform retail lookups). Using the new higher level slot-based interface greatly simplifies nodeIndexonlyscan.c, which no longer has to deal with the visibility map directly. More importantly, this is a significant architectural improvement: table AMs can now implement index-only scans that are not tied to heapam's visibility map. Two users of the now removed table_index_fetch_tuple interface, _bt_check_unique and unique_key_recheck, fundamentally need to pass a TID to the table AM to perform constraint enforcement. Neither actually performs an index scan (even though their TIDs are taken from an index), so neither has any use for most of the index scan machinery. Switch these callers over to fetch_tid, a new special-purpose table AM interface for constraint enforcement code. All true index scan callers now use the new slot-based interface. (Note that fetch_tid doesn't perform on-access pruning, which matches how things worked prior to Postgres 12 commits c2fe139c2 and 71bdc99d0.) The VISITED_PAGES_LIMIT mechanism used by get_actual_variable_range to cap scan overhead during planning is reworked to go through a new scan descriptor field (xs_visited_pages_limit), rather than having selfuncs.c count heap page fetches and terminate the scan itself. This is necessary because callers that use the new slot-based interface no longer have direct access to which heap blocks were fetched. Similarly, nodeIndexonlyscan.c can no longer use InstrCountTuples2 to count heap fetches during an EXPLAIN ANALYZE. EXPLAIN ANALYZE now obtains this information from a new IndexScanInstrumentation field, which table AMs are required to maintain during index-only scans. Though independently useful, this commit is preparatory work for an upcoming commit that will add an amgetbatch index AM interface, where the table AM takes full responsibility for managing the progress of index scans. The table AM determines when to request the next batch from the index AM, at a time of its choosing. A follow-on commit will rely on this to prefetch table blocks during index scans. Having a single entry point for all index scan callers unambiguously puts the table AM in control of the scan. Author: Peter Geoghegan Reviewed-by: Andres Freund Reviewed-by: Tomas Vondra Reviewed-by: Rui Zhao Discussion: https://postgr.es/m/CAH2-WzmYqhacBH161peAWb5eF=Ja7CFAQ+0jSEMq=qnfLVTOOg@mail.gmail.com

Revert UPDATE/DELETE FOR PORTION OF

2026-09-15T10:12:37Z

List of commits reverted: 8e72d914c52 Add UPDATE/DELETE FOR PORTION OF b6ccd30d8ff Add isolation tests for UPDATE/DELETE FOR PORTION OF 33db6c4baf1 Fix DELETE/UPDATE FOR PORTION OF with rules 7b22f15a015 Add psql tab completion for FOR PORTION OF clause 7ca8c942967 Fix FOR PORTION OF with non-updatable view columns 993a7aa0e4a Fix cross-leftover pollution in FOR PORTION OF insert triggers 7ac030d5b15 Require UPDATE permission on FOR PORTION OF column f0aedc7cb0e Small terminology fixes in comments 7d13b03a2e6 Fix FOR PORTION OF for inheritance children a272a58b942 Move FOR PORTION OF volatile check into planner a40fdf65886 Reject child partition FDWs in FOR PORTION OF bc3ae886a75 Forbid FOR PORTION OF with WHERE CURRENT OF e994f956e48 Forbid generated columns in FOR PORTION OF dfce19c2300 Forbid FOR PORTION OF on views with INSTEAD OF triggers 20fe90bbb93 Fix RLS checks for FOR PORTION OF leftover rows 9170c8b7169 Test what BEFORE UPDATE triggers do to FOR PORTION OF 7090c696cc9 Deparse FOR PORTION OF using the range column's current name. 62d1a5f8be8 Avoid RETURNING side effects for FOR PORTION OF leftovers. 9924e2d900b Enforce WITH CHECK OPTION on DELETE FOR PORTION OF leftovers c16a1b4f2ce Fix error code for null FOR PORTION OF target 610976420a3 Fix assertion failures in DELETE FOR PORTION OF tuple routing 438f027238c Resolve untyped parameters in FOR PORTION OF FROM/TO bounds 140fdfcdf12 Don't evaluate the FOR PORTION OF target under EXPLAIN Discussion: https://www.postgresql.org/message-id/62bf70cc-dc33-4188-8070-a8c177bb61de%40eisentraut.org

Close relations opened specifically for AFTER triggers

2026-08-26T14:40:23Z

39dcfda2d fixed an incorrect reuse of ResultRelInfos for AFTER triggers when the ResultRelInfo needed to have a different ri_RootResultRelInfo. That caused an issue in logical replication apply workers as finish_edata() neglects to call ExecCloseResultRelations() and instead relies on ExecCleanupTupleRouting() to close relations opened during partitioning's tuple routing. Since 39dcfda2d, because we may have done some additional table_opens() calls due to having to create an additional ResultRelInfo because of requirements to have a different ri_RootResultRelInfo, we should now be explicitly closing any relations opened on ResultRelInfos in EState's es_trig_target_relations. Since finish_edate() seems to want to avoid calling ExecCloseResultRelations(), add a new external function named ExecCloseTrigTargetRelations(). Reported-by: Hayato Kuroda (Fujitsu) Author: Hayato Kuroda (Fujitsu) Author: David Rowley Reviewed-by: Zhijie Hou (Fujitsu) Discussion: https://postgr.es/m/OS9PR01MB121491E7E05950D108AF9A6D8F5A72@OS9PR01MB12149.jpnprd01.prod.outlook.com Backpatch-through: 15

Retire execdebug.h and its debugging facility

2026-08-22T07:23:16Z

execdebug.h includes "pretty old and crufty" code used to print debugging information in the executor. As reported recently, this code has not compiled in the last 10 years or so, and there are better alternatives available, such as elog(). There is no indication that this facility is still being used, so remove it along with its associated debugging macros: EXEC_NESTLOOPDEBUG EXEC_SORTDEBUG EXEC_MERGEJOINDEBUG Reviewed-by: Tom Lane Reviewed-by: Tatsuya Kawata Discussion: https://postgr.es/m/aoFfAvp6xdk7Cdi6@paquier.xyz

Shorten pg_attribute_always_inline to pg_always_inline

2026-07-11T14:17:16Z

The pg_attribute_always_inline macro name is so long it forces pgindent to format the code in strange ways. Which may incentivize patch authors to either structure the code in strange ways (e.g. reorder prototypes), use shorter names, etc. Neither is very desirable for code readability. This shortens the name by removing the _attribute_ part. It also makes it more consistent with pg_noinline, which does not have the _attribute_ part either. Backpatched to all supported branches, to prevent conflicts when backpatching other fixes. The backbranches however keep both the old and new macro name, so that existing code keeps working. Author: Andres Freund Reviewed-by: Peter Geoghegan Reviewed-by: Tomas Vondra Discussion: https://postgr.es/m/bqqdehahpoa36igpictuqyn2s2mexk3t3ehidh2ffd2slb35e5@rzgksuiszgbg Backpatch-through: 14

Make SPI_prepare argtypes argument const

2026-06-30T13:43:56Z

This changes the argtypes argument of SPI_prepare(), SPI_prepare_cursor(), SPI_cursor_open_with_args(), and SPI_execute_with_args() from Oid *argtypes to const Oid *argtypes. The underlying functions were already receptive to that, so this doesn't require any significant changes beyond the function signatures and some internal variables. Commit 28972b6fc3dc recently introduced a case where a const had to be cast away before calling these functions. This is fixed here. In passing, make a very similar const addition to SPI_modifytuple(). Reviewed-by: Tom Lane Reviewed-by: Ewan Young Discussion: https://www.postgresql.org/message-id/flat/86b5162f-c472-40fa-997b-0450dece1dec%40eisentraut.org

Fixes for SPI "const Datum *" use

2026-06-30T12:46:15Z

Fixup for commit 8a27d418f8f, which converted many functions to use "const Datum *" instead of "Datum *", including some SPI functions. For SPI_cursor_open(), the code was updated but not the documentation. For SPI_cursor_open_with_args(), the documentation was updated but not the code. (Possibly, these two were confused with each other.) Also, SPI_execp() and SPI_modifytuple() were not updated, even though they are closely related to the functions touched by the previous commit and now look inconsistent. Fix all these. Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/flat/86b5162f-c472-40fa-997b-0450dece1dec%40eisentraut.org

Reject child partition FDWs in FOR PORTION OF

2026-06-27T17:36:51Z

We should defer validating FDW usage until after analysis. We have to guard against not just the topmost table, but also individual child partitions. Added the check to CheckValidResultRel, because it is called after looking up child partitions (accounting for pruning), but before the FDW can run a DirectModify update, which would bypass per-tuple executor work. Author: jian he Reported-by: Tom Lane Reviewed-by: Paul A. Jungwirth Discussion: https://www.postgresql.org/message-id/flat/CA%2BrenyUte0_UJsJiDJQi82oaBsMJn%3Dcct0Wn%3DvOqXtuDn%3DYYJA%40mail.gmail.com

Revert "Enable fast default for domains with non-volatile constraints"

2026-06-08T18:20:39Z

This reverts commit a0b6ef29a51818a4073a5f390ed10ef6453d5c11, along with its follow-up 2e123e3c2bd34f2377212a4e7cfcdbf9e2d9c7ff ("Silence compiler warning from older compilers"), which only adjusted code introduced by the former. The change failed with an empty table and an invalid default, and the best way to deal with that will involve an addition to the TAM API, so it's not ready for relese 19 now. Discussion: https://postgr.es/m/7033D663-DDB4-4B35-922C-F33DE53B1502@gmail.com

Pre-beta mechanical code beautification, step 1: run pgindent.

2026-05-13T14:34:17Z

Update typedefs.list from the buildfarm, and run pgindent. The changes from the new typedefs list are pretty minimal, since we'd been pretty good (not perfect) about updating typedefs.list by hand. But the pgindent behavior changes installed by a3e6beba6, b518ba4af, and 60f9467c3 add up to make this a relatively sizable diff.