Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[YSQL] Use extension binary upgrade flow for pg_stat_statements #26566

Open
1 task done
fizaaluthra opened this issue Mar 26, 2025 · 0 comments
Open
1 task done

[YSQL] Use extension binary upgrade flow for pg_stat_statements #26566

fizaaluthra opened this issue Mar 26, 2025 · 0 comments
Labels
area/ysql Yugabyte SQL (YSQL) kind/enhancement This is an enhancement of an existing feature priority/medium Medium priority issue status/awaiting-triage Issue awaiting triage

Comments

@fizaaluthra
Copy link
Member

fizaaluthra commented Mar 26, 2025

Jira Link: DB-15934

Description

Built-in extensions are not dumped in binary upgrade mode.
Presently, pg_stat_statements is a built-in extension that is created during initdb.
This works fine today, but in the future we may want to follow the binary upgrade path for this extension as well.

Issue Type

kind/enhancement

Warning: Please confirm that this issue does not contain any sensitive information

  • I confirm this issue does not contain any sensitive information.
@fizaaluthra fizaaluthra added area/ysql Yugabyte SQL (YSQL) status/awaiting-triage Issue awaiting triage labels Mar 26, 2025
@yugabyte-ci yugabyte-ci added kind/enhancement This is an enhancement of an existing feature priority/medium Medium priority issue labels Mar 26, 2025
fizaaluthra added a commit that referenced this issue Mar 31, 2025
Summary:
There's a work-around in `dumpACL` (pg_dump.c) to avoid dumping the ACL for pg_stat_statements_reset. Without this work-around, the upgrade fails with:
```
[m-1] 2025-03-27 10:43:16.146 EDT [97719] ERROR:  function pg_catalog.pg_stat_statements_reset() does not exist
[m-1] 2025-03-27 10:43:16.146 EDT [97719] STATEMENT:  SELECT pg_catalog.binary_upgrade_set_record_init_privs(true);
[m-1] 	REVOKE ALL ON FUNCTION "pg_catalog"."pg_stat_statements_reset"() FROM PUBLIC;
[m-1] 	SELECT pg_catalog.binary_upgrade_set_record_init_privs(false);
```

Postgres does not dump object definitions for built-in extensions, only their permissions. In YB, pg_stat_statements is a built-in
extension that's created as part of initdb. As a result, the pg_dump during binary upgrade does not contain the definition for the function `pg_stat_statements_reset`, but it contains an ACL dump for it. In the latest version of pg_stat_statements (1.10), this function's signature has changed (it has gained parameters). Since the reinitdb during upgrade creates the latest version of the extension, the REVOKE command above fails as `pg_stat_statements_reset()` no longer exists.

For now, keep the work-around and update the comment for the YB_TODO. In the future, we may want to follow the typical extension binary upgrade  path for pg_stat_statements (create an empty extension and manually create extension objects), and then this work-around can be removed (tracked in GH issue #26566).
Jira: DB-15943

Test Plan: Jenkins: compile only

Reviewers: telgersma, hsunder

Reviewed By: telgersma, hsunder

Subscribers: yql

Differential Revision: https://phorge.dev.yugabyte.com/D42796
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ysql Yugabyte SQL (YSQL) kind/enhancement This is an enhancement of an existing feature priority/medium Medium priority issue status/awaiting-triage Issue awaiting triage
Projects
None yet
Development

No branches or pull requests

2 participants