Don't allowing CREATE ACCESS METHOD command seems problematic for me. How could it work with pg_upgrade? pg_dump wouldn't dump extra pg_am records. So, pg_upgrade would break at creating operator classes on new cluster. So, I agree with dropping create am command only if we let pg_dump to dump extra pg_am records...
pg_dump would dump the CREATE EXTENSION command, and the extension's installation script inserts the row to pg_am. pg_dump doesn't dump objects that are part of an extension, so that's how this would work with the CREATE ACCESS METHOD command, too.
In binary upgrade mode pg_dump have to guarantee that all database objects will have same oids. That's why in binary upgrade mode pg_dump dumps extension contents instead of just CREATE EXTENSION command.
Backtracking a bit, to summarize the discussion so far:
* It would be nice to have indexes that are not WAL-logged, but are automatically re-created after a crash. But it's a completely different and orthogonal feature, so there's no need to discuss that further in this thread.
* If an extension is buggy, it can crash and corrupt the whole database. There isn't really anything we can do about that, and this patch doesn't make that any better or worse.
* CREATE ACCESS METHOD command isn't worth it.
Taking into account my previous note, how can custom extensions survive pg_upgrade without CREATE ACCESS METHOD command?
