Re: Tepid: selective index updates for heap relations

Hello, me again. :)

Here is v81, rebased on 6a3da13d376. It fixes a bug in 0019 and
resolves rebase conflicts in 0006, 0015, 0018 and 0019.

hot_indexed_on_apply = off did not turn the feature off on the apply
path. The check compared the indexed attributes to the primary key's
with bms_equal(), but every primary key column is also in the indexed
set, so that test was the same as subset_only's bms_is_subset(). With a
primary key on (a, b) and another index on (b), a replicated UPDATE of a
still went HOT-indexed under off. Nothing was lost, since off only
allowed what subset_only already allows, but the docs promise the old
behaviour. off now always takes the non-HOT path, and 039 has a table
that fails without the fix (20 of 20 updates went HOT-indexed).

The rebase conflicts:

- 0006: 398eb35f001 made the original insert tuple an explicit argument
to ExecARInsertTriggers() and ExecARUpdateTriggers(). 0006 adds the
old row image to ExecARUpdateTriggers(), so its callers now pass
both.

- 0015, 0018, 0019: test lists in Makefiles and meson.build. Upstream
added pg_upgrade's t/009_composite_types.pl, so 0018's
t/009_hot_indexed.pl is now t/011_hot_indexed.pl.

0006 and 0013 also have one-line comment fixes, 0015's 010_vm_conversion
no longer fails when run with PG_TEST_PG_UPGRADE_MODE=--swap, and the
two DO NOT MERGE patches got small cleanups. In 0021's A/A control, the
second arm queried the master server with the tepid client binaries; it
now uses the master build for both. 0001-0005, 0007-0012, 0014, 0016
and 0017 differ from v80 only by the rebase.

Attribute versioning (245eb832f88, 6a3da13d376) marks composite datums
with HEAP_XMAX_COMMITTED | HEAP_XMAX_INVALID. Nothing in the series
builds tuples with both bits set, and amcheck's new "tuple marked as
datum tuple in table" check passes on the HOT-indexed tests.

I'd still be interested to hear opinions on whether losing the
index_delete_check_htid() corruption checks on non-catalog tables is
acceptable, and whether there are index scan callers I've missed that
need to skip flagged entries.

best.

-greg