ON CONFLICT DO UPDATE command cannot affect a row a second time
-
While posting a post which was still posted.
-
@zecc said in ON CONFLICT DO UPDATE command cannot affect a row a second time:
While posting a post which was still posted.
CLOSED_WONTFIX_WORKANYWAY
-
INSERT
INSERT INSERT — create new rows in a table Synopsis [ WITH [ RECURSIVE ] with_query [, ...] ] INSERT …
INSERT with an ON CONFLICT DO UPDATE clause is a “deterministic” statement. This means that the command will not be allowed to affect any single existing row more than once
It appears that ON CONFLICT DO UPDATE cannot, indeed, affect any row a second time. There's no error, NodeBB is just informing you of this piece of trivia. Thanks, NodeBB!
-
@anonymous234 This seems like normal behavior.
@anonymous234 This seems like normal behavior.
-
The bug is that the error message doesn't list the sql query and its arguments, right?
-
@ben_lubar you aware of this yet? Looks related to the postgres migration.
-
@createdtodislikethis said in ON CONFLICT DO UPDATE command cannot affect a row a second time:
The bug is that the error message doesn't list the sql query and its arguments, right?
It should obviously present you the query in an editable form so you can fix and submit it yourself.
-
@onyx said in ON CONFLICT DO UPDATE command cannot affect a row a second time:
@createdtodislikethis said in ON CONFLICT DO UPDATE command cannot affect a row a second time:
The bug is that the error message doesn't list the sql query and its arguments, right?
It should obviously present you the query in an editable form so you can fix and submit it yourself.
Care must be taken so that if two or more users update at the same time, it won't conflict.
-
2018-07-10 15:30:16.601 UTC [22059] ERROR: ON CONFLICT DO UPDATE command cannot affect row a second time 2018-07-10 15:30:16.601 UTC [22059] HINT: Ensure that no rows proposed for insertion within the same command have duplicate constrained values. 2018-07-10 15:30:16.601 UTC [22059] STATEMENT: INSERT INTO "legacy_zset" ("_key", "value", "score") SELECT $1::TEXT, v, s FROM UNNEST($2::TEXT[], $3::NUMERIC[]) vs(v, s) ON CONFLICT ("_key", "value") DO UPDATE SET "score" = EXCLUDED."score"@julianlam this means something is telling the database to try to set the same value in a sorted set multiple times in a single call.
I also see a ton of this:
2018-07-11 12:00:05.703 UTC [9711] ERROR: payload string too long 2018-07-11 12:00:05.703 UTC [9711] STATEMENT: SELECT pg_notify('socketio', $1::TEXT)
-
@ben_lubar said in ON CONFLICT DO UPDATE command cannot affect a row a second time:
SELECT pg_notify('socketio', $1::TEXT)Seeing this makes my hair stand on its end.
And I'm not talking on the head, that hair does it all the time.
Filed under: What could possibly go wrong?
-
@ben_lubar said in ON CONFLICT DO UPDATE command cannot affect a row a second time:
I also see a ton of this:
2018-07-11 12:00:05.703 UTC [9711] ERROR: payload string too long
2018-07-11 12:00:05.703 UTC [9711] STATEMENT: SELECT pg_notify('socketio', $1::TEXT)postgres doc says:
payload
The "payload" string to be communicated along with the notification. This must be specified as a simple string literal. In the default configuration it must be shorter than 8000 bytes. (If binary data or large amounts of information need to be communicated, it's best to put it in a database table and send the key of the record.)Now I'm curious what these dropped "notifications" contain.
-
this is a test reply
-
this is my expression of disbelief in reaction to not having had a notification that there was a reply in this thread
-
@Zecc said in ON CONFLICT DO UPDATE command cannot affect a row a second time:
this is my expression of disbelief in reaction to not having had a notification that there was a reply in this thread
There wasn't. There was a reply to a different thread that was subsequently moved into this one for testing.
-
what about this one?
-
here, I'll respond to this post too
-
Those I got.
