MySQL Primary Keys - v1.15 breaks compliance with Percona Strict Mode #7830

New Issue

GiteaMirror · 2025-11-02T07:38:36-06:00

GiteaMirror commented

2025-11-02 07:38:36 -06:00

Originally created by @tacerus on GitHub (Sep 11, 2021).

Gitea version (or commit ref): v1.15.2 (binary release)
Git version: 2.31.1
Operating system: openSUSE 15.3
Database (use [x]):
- PostgreSQL
- MySQL (Percona XtraDB Cluster)
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
Log gist:

Description

Hello,

Thanks for the great software! :-)

We have been using Gitea with a Percona MySQL database and pxc_strict_mode set to ENFORCING (a Percona XtraDB setting for MySQL that, beneath other checks, blocks transactions lacking primary keys on tables - this is important, as such transactions can cause issues with the mechanism that propagates write operations to other cluster nodes) since a long time, and it has always been working fantastically. With v1.15 however, there seems to be an issue with missing primary keys in the database. as i.e. the creation of an issue will return a 500 error page, with log entries like the following example being generated:

2021/09/11 02:26:06 ...rs/web/repo/issue.go:980:NewIssuePost() [E] NewIssue: generate issue index failed: Error 1105: Percona-XtraDB-Cluster prohibits use of DML command on a table (gitea.issue_index) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER

For now we have the database servers in PERMISSIVE mode, in order for Gitea to be able to operate, however as the database cluster is in use with other services as well, this is not an ideal scenario.
I understand if Percona's distribution of MySQL is not a common use case, however would very much appreciate if the support of it could be considered as a request, or if short instructions on how to manually update the tables in the new version in order for them to include primary keys again could be provided.

Best,
Georg

Originally created by @tacerus on GitHub (Sep 11, 2021). - Gitea version (or commit ref): v1.15.2 (binary release) - Git version: 2.31.1 - Operating system: openSUSE 15.3  - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL (Percona XtraDB Cluster) - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - Log gist:    ## Description Hello, Thanks for the great software! :-) We have been using Gitea with a Percona MySQL database and `pxc_strict_mode` set to `ENFORCING` (a Percona XtraDB setting for MySQL that, beneath other checks, blocks transactions lacking primary keys on tables - this is important, as such transactions can cause issues with the mechanism that propagates write operations to other cluster nodes) since a long time, and it has always been working fantastically. With v1.15 however, there seems to be an issue with missing primary keys in the database. as i.e. the creation of an issue will return a 500 error page, with log entries like the following example being generated: ``` 2021/09/11 02:26:06 ...rs/web/repo/issue.go:980:NewIssuePost() [E] NewIssue: generate issue index failed: Error 1105: Percona-XtraDB-Cluster prohibits use of DML command on a table (gitea.issue_index) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER ``` For now we have the database servers in `PERMISSIVE` mode, in order for Gitea to be able to operate, however as the database cluster is in use with other services as well, this is not an ideal scenario. I understand if Percona's distribution of MySQL is not a common use case, however would very much appreciate if the support of it could be considered as a request, or if short instructions on how to manually update the tables in the new version in order for them to include primary keys again could be provided. Best, Georg

GiteaMirror closed this issue

2025-11-02 07:38:36 -06:00

GiteaMirror commented

2025-11-02 07:38:37 -06:00

@lunny commented on GitHub (Sep 11, 2021):

I think this has been resolved by #16820 which published in 1.15.1

@lunny commented on GitHub (Sep 11, 2021): I think this has been resolved by #16820 which published in 1.15.1

GiteaMirror commented

2025-11-02 07:38:37 -06:00

@tacerus commented on GitHub (Sep 11, 2021):

Thanks for the input! The text suggests it will ship with 1.16, but that a user on 1.15 can use gitea doctor recreate-table issue_index - does this apply to 1.15.2 as well?

@tacerus commented on GitHub (Sep 11, 2021): Thanks for the input! The text suggests it will ship with 1.16, but that a user on 1.15 can use `gitea doctor recreate-table issue_index` - does this apply to 1.15.2 as well?

GiteaMirror commented

2025-11-02 07:38:37 -06:00

@zeripath commented on GitHub (Sep 11, 2021):

Yes it applies to 1.15.2. Just run the doctor command.

(If you had upgraded straight to 1.15.2 instead of going via 1.15.0 you would not have hit this problem. Did you ever run 1.15.0?)

@zeripath commented on GitHub (Sep 11, 2021): Yes it applies to 1.15.2. Just run the doctor command. (If you had upgraded straight to 1.15.2 instead of going via 1.15.0 you would not have hit this problem. Did you ever run 1.15.0?)

GiteaMirror commented

2025-11-02 07:38:38 -06:00

@tacerus commented on GitHub (Sep 11, 2021):

Thank you very much! That worked perfectly. I upgraded directly to 1.15.2 this time, however had a failed attempt on 1.15.0 before I downgraded back to 1.14.x - there might have been some leftovers there.

@tacerus commented on GitHub (Sep 11, 2021): Thank you very much! That worked perfectly. I upgraded directly to 1.15.2 this time, however had a failed attempt on 1.15.0 before I downgraded back to 1.14.x - there might have been some leftovers there.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#7830