https://authzed.com logo
Join Discord
Powered by
Hello everyone
# spicedb
t
Hello everyone I'm having an issue with a relationship that is not being returned on readRelationships (with fullyConsistent: true) . I checked the database and it is there. After using operation_touch and rewriting it, it started returning it correctly. The old relationship was deleted and a new one created, identically, so I'm not sure what was wrong. Any tips on what might have caused that?
After recreated, the only difference I noticed was the created_xid. The old one had 9 digits while the new one only has 8
y
there's a chance that old xid was postgres maxint, and that would likely mean it fell outside of the window that SpiceDB was reading in. how did you originally write that relation?
t
I see. Pretty sure it was through the write api
y
yeah, that's odd and unexpected. is there anything obvious about the row? is there replication in play? is this postgres we're talking about?
t
Yeah, its postgresql. I couldn't find anything out of the ordinary so far
y
is that row with the weird txid the most recently-created row?
t
most-recently would be the highest number, correct?
y
not necessarily
the transaction counter shouldn't be jumping by an order of magnitude
and it's a number that you can modify
(e.g. you can technically delete rows in spicedb by setting the 
deleted_xid
to a small number and letting the garbage collection remove them. we don't recommend doing this, but it's an illustration of a part of how it works.)
t
Is there any way I can query all rows with created_xid > 8 digits?
It seems that all of them are not being read
And whats the threshold that spicedb uses? In other words, how do I know if a row is not being read because of its created_xid?
y
it's not static
if you're using 
fully_consistent
consistency, it's checking the current snapshot id (same output as 
pg_current_xact_id()
) and looking for things whose created_xid is before that and whose deleted_xid is either after it or the max int
if you're using zedtokens, that zedtoken corresponds to a txid
t
So for some reason, these tuples were created with a txid higher than the pg_current_xact_id(), is that correct?
y
and if you're using 
minimize_latency
, it's using a txid that falls within the quantization window
yeah, that's my guess as to what's happening
the discontinuity in the txids is weird
and it not reading those values out is consistent with the way that txids are handled
i'd check this if you have the ability to run directly against the datastore in question
t
Yeah, I just checked it and its currently on 71688415
So it checks out
I'll search every row with created_xid higher than this, and recreate them. I guess that should fix it
These rows might be related with a migration we did a while back. We moved the database to another region. Would that affect the txid?
y
yes
did you use 
pg_dump
and 
pg_restore
?
the content of the rows would reflect the txid state of the old database, while the new database would have a much lower transaction counter
we recommend using 
zed backup create
and 
zed backup restore
for that reason
(though that can't be done online)
and 
zed datastore repair
is something that you can run after setting up logical replication or doing a 
pg_dump
and 
pg_restore
to reset the txid counter according to the data you've got
9 Views
PreviousNext
Powered by