| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Sofia Kopikova <s(dot)kopikova(at)postgrespro(dot)ru> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Add TOAST support for more system tables |
| Date: | 2023-07-17 22:31:04 |
| Message-ID: | 4092511.1689633064@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Sofia Kopikova <s(dot)kopikova(at)postgrespro(dot)ru> writes:
> This patch adds TOAST support for system tables pg_class,
> pg_attribute and pg_largeobject_metadata, as they include ACL columns,
> which may be potentially large in size.
We have been around on this topic before, cf discussion leading up to
commit 96cdeae07. Allowing toasted data in pg_class or pg_attribute
seems quite scary to me because of the potential for recursive access,
particularly during cache-flush scenarios. (That is, you need to be
able to read those catalogs on the way to fetching a toasted value,
so how can you be sure that doesn't devolve into an infinite loop?)
I wonder whether we'd be better off shoving the ACL data out of
these catalogs and putting it somewhere else (compare pg_attrdef).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2023-07-17 23:08:03 | Re: Atomic ops for unlogged LSN |
| Previous Message | Michael Paquier | 2023-07-17 22:27:02 | Re: ObjectIdGetDatum() missing from SearchSysCache*() callers |