Missing TOAST table for pg_class
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t42975psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 02:26 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t42975_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t42975_1 && git checkout t42975_1Patchset v1 (message #1) is on t42975_1
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
=?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