A question regarding deleting relationships for postgres, how does this work? From what I can tell, it just sets the deleted_xid. I'm definitely missing a piece of information of how this operates

That’s how it marks the relationship deleted but leaves it available for historical snapshot queries. After the gc window (a spicedb config parameter) a gc process comes by and deletes the row.

Ah that makes sense. On the gc, what are the default settings? I've just got a load of very old relationships that need to purged, and not occupy space in the table

I believe the default is 25h.

Okay cool, and it will purge deleted relationships older than that? Is there a way to 'force' a gc to run?

Check out the datastore gc window and datastore gc frequency command line flags for setting these parameters

We have autovacuum set on the table - it should run pretty frequently. It would be nice to have an endpoint/parameter to 'force' gc for given parameters, I would rather not manually run the sql query.

For reference, from

spicedb serve --help

--datastore-gc-interval duration                                  amount of time between passes of garbage collection (postgres driver only) (default 3m0s)
      --datastore-gc-max-operation-time duration                        maximum amount of time a garbage collection pass can operate before timing out (postgres driver only) (default 1m0s)
      --datastore-gc-window duration                                    amount of time before revisions are garbage collected (default 24h0m0s)

Ah - we are currently running the latest version v.127.0, and postgres 15, so hopefully this shouldn't be an issue for us

let me double check but I think there may be a command for that already

Oh nice, that's super helpful

happy to help!

After running this manually, I have noticed that the automatic garbage collection is not running It instead fails with: { "level": "warn", "error": "error retrieving watermark: no rows in result set", "next-attempt-in": 3707098.236455, "time": "2023-12-08T10:22:27Z", "message": "error attempting to perform garbage collection" }

@Will Thornton that's odd, it would imply that the GC command deleted transaction 1 (which is added by the migrate command when you first initialize your SpiceDB cluster), or that it was never there, or perhaps that you guys manually deleted it at some point directly in the database. I couldn't reproduce this locally after running

spicedb datastore gc

on the postgres datastore. Would you mind sharing the command arguments you used?

Yeah of course, I ran

spicedb datastore gc --datastore-conn-uri <postgres_uri> --datastore-gc-window=5m --datastore-engine postgres

ah yeah, I see what's going on. And is precisely the fact that the GC window used by the server is larger than the GC window used by the command. When SpiceDB queries to get the most recent transaction outside of the GC window, it will find none, and the error will happen. The error is not problematic by itself, and it will eventually go away when the last revision makes is outside of the GC window defined in SpiceDB.

Nice thanks for confirming that suspicion

I also have another question regarding the GC config for the spiceDB. I am now trying to run the spiceDB with the operator, but unfortunately I found that the related parameter (such as the gc-window) looks like is not supported by the current config implementation in the operator (i.e https://github.com/authzed/spicedb-operator/blob/dd54d291a3d09241be71ffb828202e6945808bcf/pkg/config/config.go#L468). Is there another way to adjust the GC config (such as changing the GC window) when running with the operator?

@6enjamin99 I believe the operator will forward any unknown flag via a passthrough: https://github.com/authzed/spicedb-operator/blob/c94d78b9c597eba8337d105ba742726db0674c6d/pkg/config/config.go#L466-L469

cool, thx for the timely replies.