On 8/25/24 17:36, Marcelo Zabani wrote: >> we do some special stuff for catalogs > > That is good to know, thanks! > >> I believe you could actually lock the pg_class rows for update. Just > add FOR UPDATE at the end of the query. > > Thanks, but I tried that and got "ERROR: permission denied for table > pg_class", even if I try it only for tables the user owns. > Yeah, I tried that with a superuser, I didn't realize it'd fail for regular users who don't have rights to modify pg_class directly. > At least considering the use-case of avoiding this error due to > temporary tables/indexes (which are a part of normal application > execution), I was thinking of using materialized CTEs that filters those > out, and only after that using other functions that for example take > OIDs and return definitions. Other kinds of DDL that create > non-temporary tables can be "blamed" on developers in my case. > Do you think using those materialized CTEs could help? And do you think > this can be considered a bug that I should report or is it just too > edge-casey to consider? I have no idea what you mean - what would be filtered out, etc. But you can give it a try - you have a reproducer, so testing if it fails should not be that difficult. Other than that, I think you can do two things: 1) Make the application to simply retry in it sees this error. 2) Lock the objects using LOCK TABLE before running the query. regards -- Tomas Vondra
