Open jnweiger opened 3 years ago
Looks like a QNAP specific error (caused by bad timing, RAID being slow!?). I tested it on my local machine and it just works fine but that also uses SSD... On the QNAP devices it also just happens sometimes...
The database error is:
db_1 | 2021-08-10 07:54:45.169 UTC [657] ERROR: duplicate key value violates unique constraint "fs_storage_path_hash"
db_1 | 2021-08-10 07:54:45.169 UTC [657] DETAIL: Key (storage, path_hash)=(1, 3014a771cbe30761f2e9ff3272110dbf) already exists.
db_1 | 2021-08-10 07:54:45.169 UTC [657] STATEMENT: INSERT INTO "oc_filecache" ("mimepart", "mimetype", "mtime", "size", "etag", "storage_mtime", "permissions", "checksum", "parent", "path_hash", "path", "name", "storage") VALUES($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13)
db_1 | 2021-08-10 07:54:45.298 UTC [657] ERROR: current transaction is aborted, commands ignored until end of transaction block
db_1 | 2021-08-10 07:54:45.298 UTC [657] STATEMENT: UPDATE "oc_filecache" SET "mimepart" = $1, "mimetype" = $2, "mtime" = $3, "size" = $4, "etag" = $5, "storage_mtime" = $6, "permissions" = $7, "checksum" = $8, "parent" = $9, "path_hash" = $10, "path" = $11, "name" = $12, "storage" = $13 WHERE ("storage" = '1') AND ("path_hash" = '3014a771cbe30761f2e9ff3272110dbf')
EDIT: After further testing, I couldn't reproduce this anymore on any of the QNAP devices.
@JammingBen @JanAckermann have you seen an error like this before? (you have been experimenting with persistent connections on PostgreSQL)
db_1 | 2021-08-10 07:54:45.169 UTC [657] ERROR: duplicate key value violates unique constraint "fs_storage_path_hash" db_1 | 2021-08-10 07:54:45.169 UTC [657] DETAIL: Key (storage, path_hash)=(1, 3014a771cbe30761f2e9ff3272110dbf) already exists. db_1 | 2021-08-10 07:54:45.169 UTC [657] STATEMENT: INSERT INTO "oc_filecache" ("mimepart", "mimetype", "mtime", "size", "etag", "storage_mtime", "permissions", "checksum", "parent", "path_hash", "path", "name", "storage") VALUES($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13) db_1 | 2021-08-10 07:54:45.298 UTC [657] ERROR: current transaction is aborted, commands ignored until end of transaction block db_1 | 2021-08-10 07:54:45.298 UTC [657] STATEMENT: UPDATE "oc_filecache" SET "mimepart" = $1, "mimetype" = $2, "mtime" = $3, "size" = $4, "etag" = $5, "storage_mtime" = $6, "permissions" = $7, "checksum" = $8, "parent" = $9, "path_hash" = $10, "path" = $11, "name" = $12, "storage" = $13 WHERE ("storage" = '1') AND ("path_hash" = '3014a771cbe30761f2e9ff3272110dbf')
Retested with https://github.com/owncloud/qnap-packaging/releases/download/v10.8.0.0-rc3/ several times on both the slow arm machine and the faster x86 machine. Cannot reproduce on any of the machines today. :man_shrugging:
@oC-Chriddel I'd suggest this is not a blocker, on the condition that we give recommendation against using the slower arm hardware with owncloud..
Seen with ownCloud for QNAP 10.8.0 from ownCloud_10.8.0_arm-x41.qpkg (2021-07-21)
The Server log has this