Editing GitLab V18 Upgrade (section)

==Method 1: Manual Grant (via `kubectl exec` and `psql`)==

This method is good for immediate troubleshooting.

1.  **Find your PostgreSQL pod:**
If GitLab is managing its own PostgreSQL (the default for the Helm chart), find the PostgreSQL primary pod:

 kubectl get pods -l app=postgresql,release=<your-gitlab-release-name>,statefulset=postgresql-ha-postgresql -n <your-gitlab-namespace>

If you're using an external PostgreSQL, you'll need to connect to it directly using a PostgreSQL client.

2.  **Exec into the PostgreSQL pod (or connect externally):**
 kubectl exec -it <postgresql-primary-pod-name> -n <your-gitlab-namespace> -- bash

(Once inside, you might need to become the `postgres` user: `su - postgres`)

3.  **Connect to the GitLab database with `psql`:**
 psql -d gitlabhq_production -U postgres # Or your PostgreSQL superuser

(Replace `gitlabhq_production` if your database name is different, and `postgres` with your superuser if it's not the default.)

4.  **Grant the permission:**
Identify the GitLab database user (it's often `gitlab` or `gitlab-rails` if you're using the default Helm chart). You can check it in your `values.yaml` or in the `webservice` pod's environment variables.
 GRANT EXECUTE ON FUNCTION pg_catalog.pg_ls_waldir() TO <gitlab_database_user>;

For example, if your GitLab user is `gitlab`:
 GRANT EXECUTE ON FUNCTION pg_catalog.pg_ls_waldir() TO gitlab;

You might also consider granting the `pg_monitor` role to the GitLab user if that's appropriate for your security model and the version of PostgreSQL:
 GRANT pg_monitor TO <gitlab_database_user>;

'''Note:''' The `pg_monitor` role provides access to several monitoring-related functions, including `pg_ls_waldir()`, so this can be a more comprehensive solution.

5.  **Exit `psql` and the pod:**
 \q
 exit

6.  **Retry the GitLab upgrade:**
 helm upgrade <your-gitlab-release-name> gitlab/gitlab -f your_values.yaml --version <new-gitlab-version>