Thread: Missing TOAST table for pg_class
Hi all,
I know it has been discussed before [1] but one of our customers complained about something weird on one of their multi-tenancy databases (thousands of schemas with a lot of objects inside and one user by schema).
So when I checked the problem is because the missing TOAST for pg_class, and is easy to break it by just:
fabrizio=# create table foo (id int);
CREATE TABLE
fabrizio=# do
$$
begin
for i in 1..2500
loop
execute 'create user u' || i;
execute 'grant all on foo to u' || i;
end loop;
end;
$$;
ERROR: row is too big: size 8168, maximum size 8160
CONTEXT: SQL statement "grant all on foo to u2445"
PL/pgSQL function inline_code_block line 6 at EXECUTE
CREATE TABLE
fabrizio=# do
$$
begin
for i in 1..2500
loop
execute 'create user u' || i;
execute 'grant all on foo to u' || i;
end loop;
end;
$$;
ERROR: row is too big: size 8168, maximum size 8160
CONTEXT: SQL statement "grant all on foo to u2445"
PL/pgSQL function inline_code_block line 6 at EXECUTE
Attached patch adds the TOAST to pg_class, and let's open again the discussion around it.
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
Attachment
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabriziomello@gmail.com> writes:
> Attached patch adds the TOAST to pg_class, and let's open again the
> discussion around it.
What exactly do you argue has changed since the previous decision
that should cause us to change it? In particular, where is the
additional data to change our minds about the safety of such a thing?
One thing I'd want to see is some amount of testing of pg_class toast
accesses under CLOBBER_CACHE_ALWAYS and even CLOBBER_CACHE_RECURSIVELY.
AFAICT from reviewing the prior thread, nobody did any such thing.
regards, tom lane
On Tue, Sep 22, 2020 at 05:35:48PM -0400, Tom Lane wrote: > What exactly do you argue has changed since the previous decision > that should cause us to change it? In particular, where is the > additional data to change our minds about the safety of such a thing? Not sure that's safe, as we also want to avoid circular dependencies similarly for pg_class, pg_index and pg_attribute. -- Michael
Attachment
On Tue, Sep 22, 2020 at 10:57 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Sep 22, 2020 at 05:35:48PM -0400, Tom Lane wrote:
> > What exactly do you argue has changed since the previous decision
> > that should cause us to change it? In particular, where is the
> > additional data to change our minds about the safety of such a thing?
>
From a technical perspective I really don't know how to solve it, but my intention here is to raise a hand and demonstrate there are real scenarios where Postgres breaks so easily.
And unfortunately for the user perspective it sounds a bit fragile. Ok it's not a very common use case and the solution isn't easy, because if it is I'm sure it was already solved before.
> Not sure that's safe, as we also want to avoid circular dependencies
> similarly for pg_class, pg_index and pg_attribute.>
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
On Wed, Sep 23, 2020 at 06:11:06PM -0300, Fabrízio de Royes Mello wrote: > Adding a TOAST can cause circular dependencies between those relations?? If > you don't mind can you explain more about it? The difficult task here is to make sure that we don't have any corner cases that begin to break because of those additions: https://www.postgresql.org/message-id/20180719235006.5oqjjscmp3nxjfne@alap3.anarazel.de -- Michael