Re: Large expressions in indexes can't be stored (non-TOASTable)
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Nisha Moond <nisha.moond412@gmail.com>
Cc: Euler Taveira <euler@eulerto.com>, Michael Paquier <michael@paquier.xyz>, Amit Kapila <amit.kapila16@gmail.com>, Alexander Lakhin <exclusion@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, "Jonathan S. Katz" <jkatz@postgresql.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-04-22T17:21:01Z
Lists: pgsql-hackers
On Tue, Apr 22, 2025 at 05:17:17PM +0530, Nisha Moond wrote: > Thanks for the patch! I tested it for functionality and here are a few comments: Thank you for reviewing. > 1) While testing, I noticed an unexpected behavior with the new 512 > byte length restriction in place. Since there´s no explicit > restriction on the column roname´s type, it´s possible to insert an > origin name exceeding 512 bytes. For instance, can use the COPY > command -- similar to how pg_dump might dump and restore catalog > tables. > > For example: > postgres=# COPY pg_catalog.pg_replication_origin (roident, roname) FROM stdin; > Enter data to be copied followed by a newline. > End with a backslash and a period on a line by itself, or an EOF signal. > >> 44 regress_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa... [>512 bytes string] > >> \. > COPY 1 > > Once inserted, I was able to use the pg_replication_origin_xxx > functions with this origin name without any errors. > Not sure how common pg_dump/restore of catalog tables is in real > systems, but should we still consider if this behavior is acceptable? I'm personally not too worried about this. The limit is primarily there to provide a nicer ERROR than "row is too big", which AFAICT is the worst-case scenario if you go to the trouble of setting allow_system_table_mods and modifying shared catalogs directly. > 5) As Euler pointed out, logical replication already has a built-in > restriction for internally assigned origin names, limiting them to > NAMEDATALEN. Given that, only the SQL function > pg_replication_origin_create() is capable of creating longer origin > names. Would it make sense to consider moving the check into > pg_replication_origin_create() itself, since it seems redundant for > all other callers? > That said, if there's a possibility of future callers needing this > restriction at a lower level, it may be reasonable to leave it as is. pg_replication_origin_create() might be a better place. After all, that's where we're enforcing the name doesn't start with "pg_" and, for testing, _does_ start with "regress_". Plus, it seems highly unlikely that any other callers of replorigin_create() will ever provide names longer than 512 bytes. -- nathan
Commits
-
Ensure we have a snapshot when updating various system catalogs.
- fe8ea7a2a893 17.6 landed
- ddfcfb7cec68 15.14 landed
- b7ba2c0308ce 13.22 landed
- b65be6ef00e2 14.19 landed
- 706054b11b95 18.0 landed
- 24135398f1e1 16.10 landed
-
Remove pg_replication_origin's TOAST table.
- 16bf24e0e471 18.0 landed
-
Restrict password hash length.
- 8275325a06ed 18.0 cited
-
Ensure we have a snapshot when updating pg_index entries.
- b52adbad4674 18.0 landed
-
Add TOAST table to pg_index.
- b52c4fc3c09e 18.0 landed
-
Add toast tables to most system catalogs
- 96cdeae07f93 12.0 cited