[PATCH] Add TOAST support for several system tables
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:t45413psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 03:31 PM.
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 t45413_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 t45413_1 && git checkout t45413_1Patchset v1 (message #1) is on t45413_1
Hi, hackers
ACL lists in tables may potentially be large in size. I suggest adding TOAST support for system tables, namely pg_class, pg_attribute and pg_largeobject_metadata, for they include ACL columns.
In commit 96cdeae0 these tables were missed because of possible conflicts with VACUUM FULL and problem with seeing a non-empty new cluster by pg_upgrade. Given patch fixes both expected bugs. Also patch adds a new regress test for checking TOAST properly working with ACL attributes. Suggested feature has been used in Postgres Pro Enterprise for a long time, and it helps with large ACL's.
The VACUUM FULL bug is detailed here:
/messages/by-id/CAPpHfdu3PJUzHpQrvJ5RC9bEX_bZ6LwX52kBpb0EiD_9e3Np5g@mail.gmail.com
Looking forward to your comments
--
Sofia Kopikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
=?UTF-8?B?U29maWEgS29waWtvdmE=?= <s.kopikova@postgrespro.ru> writes:
ACL lists in tables may potentially be large in size. I suggest adding TOAST support for system tables, namely pg_class, pg_attribute and pg_largeobject_metadata, for they include ACL columns.
TBH, the idea of adding a toast table to pg_class scares the daylights
out of me. I do not for one minute believe that you've fixed every
problem that will cause, nor do I think "allow wider ACLs" is a
compelling enough reason to take the risk.
I wonder if it'd be practical to move the ACLs for relations
and attributes into some new table, indexed like pg_depend or
pg_description, so that we could dodge that whole problem.
pg_attrdef is a prototype for how this could work.
(Obviously, once we had such a table the ACLs for other things
could be put in it, but I'm not sure that the ensuing breakage
would be justified for other sorts of objects.)
regards, tom lane
On 2022-02-28 18:08:48 -0500, Tom Lane wrote:
=?UTF-8?B?U29maWEgS29waWtvdmE=?= <s.kopikova@postgrespro.ru> writes:
ACL lists in tables may potentially be large in size. I suggest adding TOAST support for system tables, namely pg_class, pg_attribute and pg_largeobject_metadata, for they include ACL columns.
TBH, the idea of adding a toast table to pg_class scares the daylights
out of me. I do not for one minute believe that you've fixed every
problem that will cause, nor do I think "allow wider ACLs" is a
compelling enough reason to take the risk.I wonder if it'd be practical to move the ACLs for relations
and attributes into some new table, indexed like pg_depend or
pg_description, so that we could dodge that whole problem.
pg_attrdef is a prototype for how this could work.(Obviously, once we had such a table the ACLs for other things
could be put in it, but I'm not sure that the ensuing breakage
would be justified for other sorts of objects.)
As there has been no progress since this email, I'm marking this CF entry as
returned with feedback for now.
- Andres