Missing TOAST table for pg_class
Hi all,
I know it has been discussed before [1]/messages/by-id/84ddff04-f122-784b-b6c5-3536804495f8@joeconway.com 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
Attached patch adds the TOAST to pg_class, and let's open again the
discussion around it.
Regards,
[1]: /messages/by-id/84ddff04-f122-784b-b6c5-3536804495f8@joeconway.com
/messages/by-id/84ddff04-f122-784b-b6c5-3536804495f8@joeconway.com
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
Attachments:
add_toast_to_pg_class_v1.patchtext/x-patch; charset=US-ASCII; name=add_toast_to_pg_class_v1.patchDownload
diff --git a/src/include/catalog/toasting.h b/src/include/catalog/toasting.h
index 51491c4513..729bc2cc66 100644
--- a/src/include/catalog/toasting.h
+++ b/src/include/catalog/toasting.h
@@ -51,6 +51,7 @@ extern void BootstrapToastTable(char *relName,
/* normal catalogs */
DECLARE_TOAST(pg_aggregate, 4159, 4160);
DECLARE_TOAST(pg_attrdef, 2830, 2831);
+DECLARE_TOAST(pg_class, 4179, 4180);
DECLARE_TOAST(pg_collation, 4161, 4162);
DECLARE_TOAST(pg_constraint, 2832, 2833);
DECLARE_TOAST(pg_default_acl, 4143, 4144);
diff --git a/src/test/regress/expected/misc_sanity.out b/src/test/regress/expected/misc_sanity.out
index 8538173ff8..0a2f5cc2a2 100644
--- a/src/test/regress/expected/misc_sanity.out
+++ b/src/test/regress/expected/misc_sanity.out
@@ -100,12 +100,9 @@ ORDER BY 1, 2;
pg_attribute | attfdwoptions | text[]
pg_attribute | attmissingval | anyarray
pg_attribute | attoptions | text[]
- pg_class | relacl | aclitem[]
- pg_class | reloptions | text[]
- pg_class | relpartbound | pg_node_tree
pg_index | indexprs | pg_node_tree
pg_index | indpred | pg_node_tree
pg_largeobject | data | bytea
pg_largeobject_metadata | lomacl | aclitem[]
-(11 rows)
+(8 rows)
=?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
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.
Adding a TOAST can cause circular dependencies between those relations?? If
you don't mind can you explain more about it?
Regards,
--
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:
/messages/by-id/20180719235006.5oqjjscmp3nxjfne@alap3.anarazel.de
--
Michael