Skip to content

PG-2424 PostgreSQL 19 support - #806

Open
artemgavrilov wants to merge 9 commits into
mainfrom
PG-2424-pg19
Open

PG-2424 PostgreSQL 19 support#806
artemgavrilov wants to merge 9 commits into
mainfrom
PG-2424-pg19

Conversation

@artemgavrilov

@artemgavrilov artemgavrilov commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

@artemgavrilov
artemgavrilov force-pushed the PG-2424-pg19 branch 3 times, most recently from 19a2402 to fed60d2 Compare July 31, 2026 14:07
@codecov

codecov Bot commented Jul 31, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 86.84211% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.08%. Comparing base (8bd27c7) to head (96a3336).
⚠️ Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
src/pg_stat_monitor.c 86.84% 0 Missing and 5 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #806      +/-   ##
==========================================
- Coverage   88.57%   88.08%   -0.49%     
==========================================
  Files           3        3              
  Lines        1304     1318      +14     
  Branches      180      183       +3     
==========================================
+ Hits         1155     1161       +6     
- Misses         75       80       +5     
- Partials       74       77       +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@artemgavrilov
artemgavrilov marked this pull request as ready for review July 31, 2026 16:17

@jeltz jeltz left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have not reviewed what actually changed in PGSS.

Comment thread regression/expected/decode_error_level_1.out Outdated
name: Build
runs-on: ${{ inputs.os }}
timeout-minutes: 10
timeout-minutes: 15

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this change necessary?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also is this really the right commit?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests run for PG19 takes slightly more time. It was added to this commit to make it atomic, so CI will pass together with PG19 related changes.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so then it is just in the wrong commit.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you want this to be separate commit anyway?

Comment thread regression/expected/level_tracking_2.out
Comment thread src/pg_stat_monitor.c
Comment thread src/pg_stat_monitor.c Outdated
Comment thread src/pg_stat_monitor.c Outdated
Comment thread .github/workflows/pmm-integration.yml
Comment thread src/pg_stat_monitor.c Outdated
@jeltz

jeltz commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Do we need to support RELKIND_PROPGRAPH in pgsm_ExecutorCheckPerms() like we support views?

@artemgavrilov
artemgavrilov force-pushed the PG-2424-pg19 branch 4 times, most recently from 958ddb5 to fed3a0b Compare August 4, 2026 17:04
@artemgavrilov

Copy link
Copy Markdown
Contributor Author

Do we need to support RELKIND_PROPGRAPH in pgsm_ExecutorCheckPerms() like we support views?

Added

@artemgavrilov
artemgavrilov requested a review from jeltz August 4, 2026 17:17
@adeshthack

adeshthack commented Aug 4, 2026

Copy link
Copy Markdown

what are the concerns regarding changes in PGSS that are being referenced here?

@jeltz

jeltz commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

@adeshthack The main thing was ComputeConstantLengths() and the addition of counts of generic and custom plans.

Comment thread CHANGELOG.md Outdated

- Our name and version are now in `pg_get_loaded_modules()` for PostgreSQL 18+
- Support for `EXEC_BACKEND` builds ([PG-2547](https://perconadev.atlassian.net/browse/PG-2547))
- Add PostgreSQL 19 support ([PG-2424](https://perconadev.atlassian.net/browse/PG-2424))

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe mention the two new fields?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Property graph support should maybe also be mentioned.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment thread src/pg_stat_monitor.c
if (rte->relkind == RELKIND_VIEW)
if (rte->relkind == RELKIND_VIEW
#if PG_VERSION_NUM >= 190000
|| rte->relkind == RELKIND_PROPGRAPH

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Us even getting here show that the concidional a bit up has a typo in it. We should fix that conditional.

		if (rte->rtekind != RTE_RELATION
#if PG_VERSION_NUM >= 160000
			&& rte->rtekind != RTE_SUBQUERY && rte->relkind != RELKIND_VIEW
#endif
			)

Has a typo in it. It should have been something like && !(rte->rtekind == RTE_SUBQUERY && rte->relkind == RELKIND_VIEW).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually maybe it is even unnecessary since it cannot be true given the assertion in the PostgreSQL code, right? Maybe we should fcheck for perminfoindex or similar? But either way we should clean up the above.

			/*
			 * Only relation RTEs and subquery RTEs that were once relation
			 * RTEs (views, property graphs) have their perminfoindex set.
			 */
			Assert(rte->rtekind == RTE_RELATION ||
				   (rte->rtekind == RTE_SUBQUERY &&
					(rte->relkind == RELKIND_VIEW || rte->relkind == RELKIND_PROPGRAPH)));

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perminfoindex fits perfectly here 👍

Make pg_stat_monitor compilable against PostgreSQL 19

PostgreSQL 19 optimized SELECT ... INTO statements execution(ce8d5fe),
so some of them are no longer tracked by pg_stat_statements/pg_stat_monitor.
So we update level tracking test to address this change.

Build and test CI workflow required timeout increase as PG 19 requires
slightly more time.
There are no PostgreSQL 19 packages yet, so add this version only to
source based workflows.
pg_stat_statements introduces two new coutners in PostgreSQL 19:
- generic_plan_calls
- custom_plan_calls

These counters track how many times a prepared statement was executed
using a generic or custom plan. Backport them to pg_stat_monitor.
PostgreSQL 19 exposes ComputeConstantLengths function, so there is no
more reasons to compute constant lenght with our own implemenation.
In PostgreSQL 19 some pg_stat_statements tests got updates. Backport
them to pg_stat_monitor.
Backport the upstream pg_stat_statements fix (commit b1635c16669) from
PostgreSQL 18. Mark same-location duplicates with length = -1 before
the squashed check.
Mark property graphs with * the same way as we do for views.
Condition had and issue where it was keeping all subqueries, but it
should keep only subqueries that are views or property graphs. Rewrite
it with better condition: perminfoindex is non-zero for all types of
RTEs that we need.
@artemgavrilov
artemgavrilov requested a review from jeltz August 5, 2026 14:00
@adeshthack

Copy link
Copy Markdown

@adeshthack The main thing was ComputeConstantLengths() and the addition of counts of generic and custom plans.

yea sounds good

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

PostgreSQL 19 support

3 participants