-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
PostgreSQL duplicate key value violates unique constraint
#19494
Comments
Also started getting that error recently. Not sure from which version. Does anyone know for sure how far back I need to go in version to not have this issue? |
Similar to #6343 Just a different table. I see that issue more with pgsql than Nextcloud. We have code in place to handle the duplicate key situation. The reason we try to insert a record without checking if a record already exists is performance. Some versions back a method to insert records has been added. That works by using a special command only available for pqsql and default sql for others database. Feel free to migrate the places step by step. Patches are always welcome. |
Not sure how far back to go, or what special command to use. You submitted a patch for the oc_credentials table, is there something similar than can be for this? |
@kesselb Is that based on any measurement? Having two trivial SQL queries instead of one doesn't look like something performance critical to my (untrained) eyes. |
@lukasjuhrich no. Each RDBMS has their own way to implement upserts. Upsert for PostgreSQL, Insert Ignore for MySQL / MariaDB. The database abstraction layer used by Nextcloud is Doctrine and does not support upsert or insert ignore. To use that features we have to implement that in Nextcloud. That's actually something I don't want to do. It just adds more trouble (see the issues with the upsert implementation we already had). A long known workaround for that issue is try to update and insert on failure. For some reason PostgreSQL logs those error messages since newer versions. We may workaround that limitation with a select upfront but you still have the timeframe between the select and insert/update for another process / request to create that record. You still need everything like before plus the additional select query. Probably there are better way to workaround that issues nowdays. Everyone is invited to submit patches and propose better ways to handle such cases. Likely there are issues with the database design / schema. That could be something to start with. From my point of view that strict duplicate key value handling (without a option to turn it off) is something that makes PostgreSQL a hard choice for PHP based application because the level of concurrency that is required to not trigger that warnings is hard to achieve. I don't work for Nextcloud GmbH and contribute to Nextcloud as home user. If you need that fixed for your professional setup you may contact Nextcloud GmbH. |
See also #13721 |
I see this each time I modify a file, still present in nextcloud 22.2.3
|
Also another duplocate key value... |
Don't know if this helps, but saw this in a log with similar issues:
Problem description from customer: It appears to be very slow. Calling the „settings“ page takes 30-45seconds. |
I found this even in nextcloud CI while googling: 😅 |
This also happens with Nextcloud 21. Nextcloud version: 21.0.9
|
All versions are affected, but <22 is eol. |
The error messages complain about the I did not check the code, so this is purely speculative: Is the workaround that is done the other way around? That is: Try the If that speculation happens to be true, this means that the error messages as are generated by that workaround are a nuisance, but a harmless one. |
Still relevant. Current setup includes:
|
Same here, using Nextcloud AIO 26.0.3. Tons of these:
|
@szaimen is using |
duplicate key value violates unique constraint
Just encountered the same problem on 27.0.2. |
Still present on 27.1.4 (with relatively high frequency - logs below for a single-user instance). This seems to only affect the
|
Same Problem Nextcloud Hub 7 (28.0.2)
|
Still relevant. Single user instance. Almost can't upload files without constant 504 gateway errors. Is there any fix?
|
this happens on other tables as well:
|
This comment was marked as off-topic.
This comment was marked as off-topic.
To summarize the situation: We added the table filecache_extended to store metadata_etag, creation_time and upload_time1. The information in filecache_extended is optional, and it's okay for filecache and filecache_extended to have a different row count. If the clients pass creation_time, then there's an additional query to store the creation_time in filecache_extended. The approach is to try to insert a new row and if that fails with a unique constraint violation update the existing one2. Possible solutions:
Curl request to trigger such a warning on pqsql:
Run it twice, the important piece is the X-OC-CTime header to trigger the insert/update for filecache_extended. Footnotes |
Would it be possible to use the database backends' native capability to deal with this situation in a single statement instead of stringing it together at the application level with separate INSERT & UPDATE statements?
|
Sure, but unfortunately the Doctrine library does not support it. There are some extensions to it like in https://github.com/nextcloud/server/blob/master/lib/private/DB/AdapterPgSql.php#L26 but it need to adopted for this case. |
Thanks for the explanation @J0WI! |
Hello!
The table pg_stat_activity constantly accumulates requests of the type:
Their number can be more than 130 |
I've prepared a pull request last week for the filecache extended table: #48564 We can't merge the patch yet because the CI is failing. The issue is that our insertIgnoreConflict implementation doesn't support sharding. Sharding, as you know, is something we're working on to distribute the filecache table across multiple database instances. Here are the alternatives:
I'll ping the files team to discuss the best way forward. |
Steps to reproduce
Expected behaviour
Ideally no errors in the Postgres log
Actual behaviour
Same error repeating over and over
Server configuration
Operating system: Custom Dockerfile
Web server: Nginx Docker mainline
Database: Postgres 11-alpine Docker image (11.5 currently)
PHP version: 7.3.14
Nextcloud version: 18.0.1
Updated from an older Nextcloud/ownCloud or fresh install: Updated from 17.0.3
Where did you install Nextcloud from: Download/extract bz2 in a custom Dockerfile
Signing status:
List of activated apps:
App list
Nextcloud configuration:
Config report
Are you using external storage, if yes which one: NFS
Are you using encryption: yes ZFS encrypted volume
Are you using an external user-backend, if yes which one: no
Client configuration
Browser: Firefox/Any
Operating system: N/A Or Any
Logs
Web server error log
Web server error log
Nextcloud log (data/nextcloud.log)
Nextcloud log
The text was updated successfully, but these errors were encountered: