Re: Table AM and DROP TABLE [ Was: Table AM and DDLs]

On 05.04.2021 22:57, Mats Kindahl wrote:
> Now, suppose that we want to replace the storage layer with a
> different one. It is straightforward to replace it by implementing the
> Table AM methods above, but we are missing a callback on dropping the
> table. If we have that, we can record the table-to-be-dropped in a
> similar manner to how the heap AM does it and register a transaction
> callback using RegisterXactCallback.

This explanation makes sense, and the suggested patch makes it easier to
replace the storage layer with a different one.

Some other places might become problematic if we're trying to implement
fully memory-based tables. For example, the heap_create_with_catalog ->
GetNewRelFilenode -> access() call that directly checks the existence of
a file bypassing the smgr layer. But I think that adding a symmetric
callback to the tableam layer can be a good start for further experiments.

Some nitpicks:

+ /*
+ * This callback needs to remove all associations with the relation `rel`
+ * since the relation is being dropped.
+ *
+ * See also table_relation_reset_filenode().
+ */

"Remove all associations" sounds vague, maybe something like "schedule
the relation files to be deleted at transaction commit"?

+ void (*relation_reset_filenode) (Relation rel);

This line uses spaces instead of tabs.

For the reference, there is a recent patch that makes the smgr layer
itself pluggable:
https://www.postgresql.org/message-id/flat/1dc080496f58ce5375778baed0c0fbcc%40postgrespro.ru#502a1278ad8fce6ae85c08b4806c2289

--
Alexander Kuzmenkov
https://www.timescale.com/