MIME-Version: 1.0
References: <CACgY3QYe3mqMkODOzwx=EN4iGoddObUotLL8hGnCg==3vmxd_g@mail.gmail.com>
 <73bc7752-442c-4c67-a263-46017f1948cc@vondra.me> <CACgY3QYdsYyZQR0hDYFLrk42OJcNOkbW4nfmrauN7byad=6f0A@mail.gmail.com>
 <4fb5ab14-80c6-4ca8-b451-df3cbcacd92f@aklaver.com>
In-Reply-To: <4fb5ab14-80c6-4ca8-b451-df3cbcacd92f@aklaver.com>
From: Marcelo Zabani <mzabani@gmail.com>
Date: Sun, 25 Aug 2024 14:14:03 -0300
Message-ID: <CACgY3QYSRBiKttYrXc6R7v+Ximt6ET+u9oSamBrLGXuabFB5jQ@mail.gmail.com>
Subject: Re: ERROR: could not open relation with OID XXXX
To: Adrian Klaver <adrian.klaver@aklaver.com>
Cc: Tomas Vondra <tomas@vondra.me>, pgsql-general@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000004262ce06208523b6"
Archived-At: <https://www.postgresql.org/message-id/CACgY3QYSRBiKttYrXc6R7v%2BXimt6ET%2Bu9oSamBrLGXuabFB5jQ%40mail.gmail.com>
Precedence: bulk

--0000000000004262ce06208523b6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFPM Adrian Klaver <adrian.klaver@aklave=
r.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.klaver@aklaver.com
>
>

--0000000000004262ce06208523b6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Thank you all for your comments.</div><div><br></div>=
<div>&gt; I would think that the queries in that case would be running as a=
 <br>
superuser in order to do the migrations.</div><div><br></div><div>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 us=
e the _postgres_ user to create the application&#39;s database, for example=
) and users are free to add statements like `SET ROLE` inside their migrati=
ons, too. So it&#39;s sadly not possible AFAICT to force superuser onto the=
m.</div><div><br></div><div>But I think I have plenty of things to try to a=
void this problem, from retrying like Tomas suggested to materialized CTEs =
that filter out temporary relations before functions like pg_get_indexdef a=
re called.<br></div><div><br></div><div>I will give these things a shot.</d=
iv><div><br></div><div>Regards.<br></div></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Aug 25, 2024 at 1:13=E2=80=
=AFPM Adrian Klaver &lt;<a href=3D"mailto:adrian.klaver@aklaver.com">adrian=
.klaver@aklaver.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">On 8/25/24 08:36, Marcelo Zabani wrote:<br>
&gt;=C2=A0 &gt; we do some special stuff for catalogs<br>
&gt; <br>
&gt; That is good to know, thanks!<br>
&gt; <br>
&gt;=C2=A0 &gt; I believe you could actually lock the pg_class rows for upd=
ate. Just <br>
&gt; add FOR UPDATE at the end of the query.<br>
&gt; <br>
&gt; Thanks, but I tried that and got &quot;ERROR: =C2=A0permission denied =
for table <br>
&gt; pg_class&quot;, even if I try it only for tables the user owns.<br>
&gt; <br>
<br>
As I understand it this issue came up in:<br>
<br>
<a href=3D"https://github.com/mzabani/codd" rel=3D"noreferrer" target=3D"_b=
lank">https://github.com/mzabani/codd</a><br>
<br>
I would think that the queries in that case would be running as a <br>
superuser in order to do the migrations.<br>
<br>
-- <br>
Adrian Klaver<br>
<a href=3D"mailto:adrian.klaver@aklaver.com" target=3D"_blank">adrian.klave=
r@aklaver.com</a><br>
<br>
</blockquote></div>

--0000000000004262ce06208523b6--