heapam_relation_toast_am() returns the wrong AM for a wrapped heap AM

Hi,

heapam_relation_toast_am() returns rel->rd_rel->relam instead of the
literal heap AM oid, on the assumption the two are always equal since
it's only meant to run for relations that are themselves heap. That
breaks for a table AM that copies heap's whole TableAmRoutine (via
GetHeapamTableAmRoutine()) and overrides only a few callbacks -- a
pattern heap_getnext()'s own identity check explicitly anticipates,
per its comment about allowing "regression tests that create another
AM reusing the heap handler." For such an AM, rel->rd_rel->relam is
its own oid, so NewRelationCreateToastTable() creates the TOAST table
with that AM too, and building its chunk_id/chunk_seq index then
fails in heap_getnext(), which requires rd_tableam to be literally
GetHeapamTableAmRoutine(): "only heap AM is supported" for any such
AM as soon as a table needs a TOAST table.

Fix by returning the literal HEAP_TABLE_AM_OID, which is what the
function's own comment already claims it does ("TOAST tables for
heap relations are just heap relations").

Found while testing an AM that wraps heap's storage callbacks for an
unrelated patch [1].

Not sure if we would call this a bug or just a limitation.

cheers

andrew

[1]
https://www.postgresql.org/message-id/ea1c4d33-0780-473c-96dc-1468cf733a04%40dunslane.net

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