Issue after upgrade - PG::CheckViolation: ERROR: no partition of relation "project_daily_statistics_b8088ecbd2" found for row

I updated from 18.2.0-ee.0 to 18.5.3-ee.0 and then fail to update to 18.6.1-ee.0 with the following mesage:

PG::CheckViolation: ERROR:  no partition of relation “project_daily_statistics_b8088ecbd2” found for row
DETAIL:  Partition key of the failing row contains (date) = (2025-08-01).

I tried gitlab-rake gitlab:db:create_dynamic_partitions which did not fix it.

I keep looking for other solutions, any suggestion is appreciated!

EDIT:

```console
root@git:~# gitlab-rake ‘gitlab:db:detach_partition’
rake aborted!
NoMethodError: undefined method to_sym' for nil:NilClass /opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db/detach_partition.rake:25:in block (3 levels) in <top (required)>’
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db/detach_partition.rake:133:in block (3 levels) in <top (required)>' /opt/gitlab/embedded/bin/bundle:25:in ’
Tasks: TOP => gitlab:db:alter_partition
(See full trace by running task with --trace)
```

apt-get install postgresql-16-partman

Did not help as such.

in gitlab-pgsql:
```
CREATE TABLE project_daily_statistics_b8088ecbd2_y2025m0801
PARTITION OF project_daily_statistics_b8088ecbd2
FOR VALUES FROM (‘2025-08-01’) TO (‘2025-08-02’);
```

Helped as it moved to the next date, I now get:

```
PG::CheckViolation: ERROR: no partition of relation “project_daily_statistics_b8088ecbd2” found for row
DETAIL: Partition key of the failing row contains (date) = (2025-08-02).
```

→ Had to drop this later DROP TABLE IF EXISTS project_daily_statistics_y2025m0801;

Also ran into:
LINE 7: ALTER TABLE “project_daily_statistics” OWNER TO “”;

So I didSo did ALTER TABLE “project_daily_statistics” OWNER TO “gitlab”;

But the script still had an empty ““ (replace_table.rb) → I changed the latter script and hardcoded “gitlab”.

That “helped”, but I got “PG::UndefinedTable: ERROR: relation “project_daily_statistics_b8088ecbd2” does not exist” .

Seems to be a rabbit-hole - downgrading is not going well either because git-reconfigure did not succeed…

To reconfigure, now at PG::UndefinedTable: ERROR: relation “project_daily_statistics_b8088ecbd2” does not exist

I tried the following and multiple other approaches (creating tables, etc) to no avail:

gitlab-rails console
irb(main):001* Gitlab::Database::Partitioning.register_tables(
irb(main):002*   [
irb(main):003*     {
irb(main):004*       limit_connection_names: %i[main],
irb(main):005*       table_name: 'project_daily_statistics_b8088ecbd2',
irb(main):006*       partitioned_column: :date,
irb(main):007*       strategy: :monthly,
irb(main):008*       retain_for: 3.months
irb(main):009*     }
irb(main):010*   ]
irb(main):011> )
irb(main):012>

To revert to the previous version I had to workaround the issue that `gitlab-ctrl register` did not complete.
I did so by adding an early return statement in replace_table in `/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/partitioning_migration_helpers/table_management_helpers.rb` to finish bypassing the blocking issue.
Then I downgraded to 18.5.3-ee.0 and restored the database for 18.5.3 .

Hi, i am also getting the same error, while doing upgrade from 18.4.5 to 18.5.3, any one can help me to fix this issue how can we avoid this error.

Thanks,

Apoorv

@le_top I was not able to upgrade, but I managed to make a downgrade…
While making a downgrade I was getting an error Malformed configuration JSON file found at /opt/gitlab/embedded/nodes/INSTANCE_NAME.json- I have remove that file and perform downgrade again - it perfectly fine for me.

Still I’m not able to make a upgrade, getting the same error as described above

Same issue here.

Can’t upgrade from 18.5.3 to 18.6.1

You wer luckier than me: I removed that file too but while trying to fix the upgrade process I think - maybe it was recreated and I did not do it again.

As I said - I was not able to upgrade, I have reverted to 18.5.3
I did:
sudo rm /opt/gitlab/embedded/nodes/INSTANCE_NAME.json
sudo apt install gitlab-ee=18.5.3-ee.0

then my instance get back, still it is 18.5.3 but it works

Same issue experienced here, upgraded from 18.4.x to 18.5.3 successfully and then 18.6.1 in the same hour.

With omnibus gitlab-ce thankfully I just had to downgrade the container version and 18.5.3 started with no changes required.

Hey there, same problem here.

I have noticed that there is a problem with completing ‘background migrations’. The task ‘BackfillPartitionedProjectDailyStatistics: project_daily_statistics’ remains in ‘finalise’ status.

I ran into the same issue when upgrading from 18.5.3-ce.0 to 18.6.1-ce.0:

PG::CheckViolation: ERROR: no partition of relation "project_daily_statistics_b8088ecbd2" found for row
DETAIL: Partition key of the failing row contains (date) = (2025-08-01).

The partitioned base table project_daily_statistics_b8088ecbd2 had partitions for 2025-09 - 2026-07 but the partition for 2025-08-01 - 2025-09-01 was missing. In my case the table existed as gitlab_partitions_dynamic.project_daily_statistics_b8088ecbd2_202508 but it was not correctly attached to the parent partition table.

Postgres did have the table but not the semantic partition binding.

Therefore:

• The partition exists
• But it’s not recognized as a valid partition
• GitLab’s installation fails during schema population

Step by step fixed that worked for me - no guarantees. Enter the psql shell: gitlab-psql -d gitlabhq_production

1. Inspect the partition tables \d+ project_daily_statistics_b8088ecbd2 → if 202508 is missing in the partition list, but the tables exists: \d+ gitlab_partitions_dynamic.project_daily_statistics_b8088ecbd2_202508 then that should be the issue
2. Attach the partition manually ALTER TABLE project_daily_statistics_b8088ecbd2
ATTACH PARTITION gitlab_partitions_dynamic.project_daily_statistics_b8088ecbd2_202508
FOR VALUES FROM ('2025-08-01') TO ('2025-09-01');
3. Verify the partition is attached \d+ project_daily_statistics_b8088ecbd2
4. Re-run gitlab-ctl reconfigure

I did this on my private instance, which is not your multi million dollar company. If you don’t wanna risk anything, wait for the GitLab staff reply

Edit: replaced weird punctuation (had this reply “cleaned up” previously)

hey there. The solution mentioned above worked for me perfectly! Thank you!

Edit: corrected typo

Awesome. @bartscherer your solution worked on my instance too.

Thanks !

We’re also seeing this error in 18.5.3 with failing background migration task: BackfillPartitionedProjectDailyStatistics: project_daily_statistics

Unfortunately the fix from @bartscherer didn’t work

gitlab=# \d+ project_daily_statistics_b8088ecbd2
Did not find any relation named "project_daily_statistics_b8088ecbd2".

Hi @mark.catalyst, I strongly assume that the suffix _b8088ecbd2 is specific to your instance and migration state. This temporary suffix is most likely generated per version of the DB schema (and probably your environment - @seba4 @sebastien.tolron did you guys change the suffix?).

Please look at your upgrade error log for the exact table name. For example:

PG::CheckViolation: ERROR: no partition of relation "project_daily_statistics_XXXXXXXXXX" found for row

Whatever hash you see instead of _b8088ecbd2, that is the one you must use in the ATTACH PARTITION SQL statement.

So the solution is the same conceptually. Just adjust the hash suffix to match your instance. This is just my current understanding of the issue, though.

I thought that might be the case, so I double checked:

PG::CheckViolation: ERROR: no partition of relation "project_daily_statistics_b8088ecbd2" found for row DETAIL: Partition key of the failing row contains (date) = (2025-08-01).

Within your first post I see gitlab=# \d+ project_daily_statistics_b8088ecbd2which seems strange to me. You’re probably using the default DB context because when entering via my command above (gitlab-psql -d gitlabhq_production), my prompt is gitlabhq_production=#. Or just use your command but when you’re in the default context switch over via \c gitlabhq_production. Hope it works. @mark.catalyst

an issue has been opened: PostgreSQL error when upgrading from 18.5.3 -> 18.6.1 (#582526) · Issues · GitLab.org / GitLab · GitLab

Hello @delaf Thank you for sharing the link! Yes, you can find the workaround in the issue - the GitLab team is working on a fix now. Sorry for the inconvenience, and thanks to the community for all the ideas and support! If you still have an issue regarding the migration please free to leave a comment on the issue. Thank you!

Hey, thanks for the suggestion, my setup just is a bit different from yours is all, gitlab=# is the name of my database.