Re: Allow table AMs to define their own reloptions

On 2026-08-14 Fr 5:46 PM, Zsolt Parragi wrote:
> Hello!
>
> +dummy_table_am behaves like a heap table but accepts a different
> +set of reloptions:
> +
> + - "fillfactor" (inherited from the core heap registration via
> + add_reloption_to_kind)
>
> +bool
> +RelationHasStdRdOptions(Relation relation)
> +{
> + if (relation->rd_options == NULL)
> + return false;
> + if (relation->rd_tableam == NULL)
> + return false;
> + return relation->rd_tableam->amoptions == NULL;
> +}
>
> dummy_table_am seems to accept but ignore fillfactor options with
> this, which based on the documentation above seem unintended?
>
> CREATE TABLE heap_ff10 (a int) WITH (fillfactor=10);
> CREATE TABLE dummy_ff10 (a int) USING dummy_table_am WITH (fillfactor=10);
>
> INSERT INTO heap_ff10 SELECT generate_series(1,200000);
> INSERT INTO dummy_ff10 SELECT generate_series(1,200000);
>
> SELECT relname, relpages,
> pg_size_pretty(pg_relation_size(oid)) AS size
> FROM pg_class
> WHERE relname IN ('heap_ff10','dummy_ff10')
> ORDER BY relname;
> relname | relpages | size
> ------------+----------+---------
> dummy_ff10 | 885 | 7080 kB
> heap_ff10 | 9091 | 71 MB
> (2 rows)
>
> Also it isn't critical for the current tests, but it doesn't seem to
> support text columns, so that contradicts the generic behaves like
> heap claim a bit:
>
> CREATE TABLE t_txt (a int, b text) USING dummy_table_am;
> ERROR: only heap AM is supported

Both of your reports are real bugs, fixed in v5. Replying to both your
email and Junwang's together.

> [Zsolt] dummy_table_am seems to accept but ignore fillfactor
> options [...]
> heap_ff10 | 9091 | 71 MB
> dummy_ff10 | 885 | 7080 kB

Confirmed, and not just fillfactor. Four macros/call sites read
StdRdOptions fields straight out of rd_options behind a check,
RelationHasStdRdOptions(), that only asked "does this AM have a
custom amoptions at all" rather than "is this field actually there"
-- blocking exactly the case add_reloption_to_kind() exists for.
Same problem for toast_tuple_target, parallel_workers,
vacuum_index_cleanup, vacuum_truncate,
vacuum_max_eager_freeze_failure_rate, and autovacuum_enabled.

Fixed with TableAmRoutine.has_std_options_prefix: an AM sets it when
its amoptions struct embeds a full StdRdOptions as its first member,
and RelationHasStdRdOptions() trusts that. dummy_table_am now embeds
StdRdOptions and registers all seven other fields too, not just
fillfactor, so each gets its real default instead of zero. Re-ran
your repro:

    dummy_ff10 | 9091 | 71 MB
    heap_ff10  | 9091 | 71 MB

Matches now. Added a regression case that fails on pre-v5, passes on v5.

> [Zsolt] doesn't seem to support text columns [...]
> ERROR: only heap AM is supported
> [Junwang] I think it's ok, it's just a test module

Also a real bug. Fixed (after some -hackers discussion) by having
dummy_table_am override relation_toast_am directly. Text columns work
now.

> [Junwang] extract_autovac_opts... unconditionally interprets the
> result as StdRdOptions, is that intentional?

It is intentional.

I think the behaviour is right: it means autovacuum's own
scheduling only ever sees the standard autovacuum_* names, never an
AM's own amoptions. (And making it AM-aware would cost a catalog lookup
on every relation in autovacuum's periodic scan, for a capability
nothing needs.) Documented that constraint in tableam.sgml rather
than leave it to be rediscovered.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com