Re: ERROR: could not open relation with OID XXXX

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(dot)klaver(at)aklaver(dot)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(dot)klaver(at)aklaver(dot)com
>
>