Thank you all for your comments. > I would think that the queries in that case would be running as a superuser in order to do the migrations.
Users of codd can choose the role that applies their migrations. Codd even supports individual migrations running with ad-hoc users (so that a migration can use the _postgres_ user to create the application's database, for example) and users are free to add statements like `SET ROLE` inside their migrations, too. So it's sadly not possible AFAICT to force superuser onto them. But I think I have plenty of things to try to avoid this problem, from retrying like Tomas suggested to materialized CTEs that filter out temporary relations before functions like pg_get_indexdef are called. I will give these things a shot. Regards. On Sun, Aug 25, 2024 at 1:13 PM Adrian Klaver <adrian.kla...@aklaver.com> wrote: > On 8/25/24 08: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. > > > > As I understand it this issue came up in: > > https://github.com/mzabani/codd > > I would think that the queries in that case would be running as a > superuser in order to do the migrations. > > -- > Adrian Klaver > adrian.kla...@aklaver.com > >
