-
-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle user referencing private tables #44
Comments
One small win: rename This is a private API, so when a user interacts with it, all bets are off. As far as I'm concerned, this is working as intended. So the improvement to be gained here is on UX of user errors.
I'm not sure how to go about warning the user that the |
Ah, my ideas where not clear when I mentioned that(they were not directly related to DELETEs). But I was thinking that we could have a guc like |
I agree. Also, right now the worker crashes/restarts forever when there's a TTL failure - it should only die once and pg_net functions should refuse to work when the worker is down. |
Another simple way is to just remove the PKs of the tables. This should also help with stability in the meantime as inserts will be faster. |
To remove the possibility of them being used as FKs Fixes supabase#44
IIRC, this issue happened because a user created a foreign key to our queue pk
pg_net/sql/pg_net.sql
Lines 11 to 12 in 5ff8b6b
Then the TTL would not work because doing DELETEs failed, this would also kill the worker on every restart.
Maybe the correct behavior in this case is to warn instead of crashing - though dying might also be good to avoid having excessive rows in the queue.
Originally posted by @steve-chavez in #43 (comment)
The text was updated successfully, but these errors were encountered: