pg_stat_get_autovacuum_scores ignores the main table's reloptions for TOAST tables

Hi all,
(CCing Nathan as the committer of 87f61f0c8280 and fad70a09ff43)

I found that pg_get_autovacuum_scores reports wrong values for TOAST
tables. In do_autovacuum(), we fall back to the main table's reloption
when the TOAST table has no reloptions of its own, and
table_recheck_autovac() does the same. However,
pg_stat_get_autovacuum_scores() only calls extract_autovac_opts() and
passes NULL when the TOAST table has none.

So the view computes the TOAST table's scores from rht eGUC defaults
whenever the user sets autovacuum_* on the main table without setting
the corresponding toast.* option. Here is a simple reproducer:

create table test (a int, b text);
alter table test alter column b set storage external;
alter table test set (autovacuum_vacuum_threshold = 1,
autovacuum_vacuum_scale_factor = 0, autovacuum_enabled = false);
insert into test select i, repeat('z',4000) from generate_series(1,200) i;
delete from test where a <= 100;
select relid::regclass, vacuum_score, do_vacuum from
pg_stat_autovacuum_scores where relid in ('test'::regclass, (select
reltoastrelid from pg_class where relname = 'test'));
relid | vacuum_score | do_vacuum
-------------------------+--------------+-----------
test | 100 | f
pg_toast.pg_toast_16384 | 6 | t
(2 rows)

And what the autovacuum worker computes for the same two relations is:

DEBUG: test: vac: 100 (thresh 1, score 100.00), ...
DEBUG: pg_toast_16384: vac: 300 (thresh 1, score 300.00), ...

Which doesn't match what the view shows.

Note that this issue happens only in v19 as commit fad70a09ff43 fixed
autovacuum's handling of TOAST reloptions. While I agree that the
commit was not backpatched to v19, I think we should fix how the view
computes the toast table's reloptions.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com