samoscyberallenh
commented
1 year ago I've been able to reproduce this using two simple transactions. First, create a VLABEL named "test" and a single vertex with that label:
create vlabel test;
create (:test {id: 1});Then in two separate sessions, run these commands:
Transaction 1 Transaction 2
------------- -------------
begin;
match (t:test {id: 1}) set t.description = 'test';
begin;
match (t:test {id: 1}) set t.description = 'other';
<transaction blocks here as expected>
commit;
ERROR: could not serialize access due to concurrent updateYou can get a similar but different message if you use DELETE instead of SET:
Transaction 1 Transaction 2
------------- -------------
begin;
match (t:test {id: 1}) delete t';
begin;
match (t:test {id: 1}) delete t;
<transaction blocks here as expected>
commit;
ERROR: unrecognized heap_update status: 4These may be separate issues, but the messages are emitted from similar parts of the code. Note that in both cases there are TODO comments (in src/backend/executor/nodeModifyGraph.c).
The first one is likely coming from the function updateElemProp:
case TM_Updated:
/* TODO: A solution to concurrent update is needed. */
ereport(ERROR,
(errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),
errmsg("could not serialize access due to concurrent update")));
break;
default:
elog(ERROR, "unrecognized heap_update status: %u", result);The second one is likely coming from a similar switch statement in the deleteElem function.
I'm not sure how to fix this problem in the core AgensGraph. For now, we're implementing an approach using PostgreSQL advisory locks to get around the problem.
Something like this:
Transaction 1 Transaction 2
------------- -------------
begin;
select pg_advisory_xact_lock(1);
match (t:test {id: 1}) set t.description = 'first';
begin;
select pg_advisory_xact_lock(1);
<transaction blocks here>
commit;
match (t:test {id: 1}) set t.description = 'second';
commit;After the above sequence, the value of the description property is "second" and there are no errors.
I'm not proposing the above as a generic workaround, just that it might be something that works for you depending on your application.It may mean that you have to run your queries twice for this to work...once to lock the IDs and once to do the update. Obviously that's not ideal. You also probably need to always acquire your locks in a prescribed order to reduce the chance of deadlocks (i.e., you probably want to sort the ID values that you're using so the locks are always acquired in order).
Hope this helps.
aviNrich
Hi, Im running my POC on branch https://github.com/bitnine-oss/agensgraph/tree/v2.14 when running the query from nodejs:
Error:
Im using https://github.com/bitnine-oss/agensgraph-nodejs . This error also generated when using, pg npm package directly.
I should mention that it is inside a transaction
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE.I Assume its something related to isolation level...
Any help would be appreciated. thanks