freenode
Databases & Infrastructure

PostgreSQL moves toward custom storage options for table access methods

A long-running patch would let non-heap table AMs own their WITH/SET parameters instead of inheriting heap’s, with dump and locking rough edges still under review.

Work is advancing on PostgreSQL support for table access methods that define and validate their own relation options, the storage parameters set with CREATE TABLE … WITH, ALTER TABLE SET, and related access-method switches.

Today, tables that use a non-heap access method can still take heap parameters such as fillfactor. The change would stop that free ride: each table AM would register the options it understands, parse and check them, and decide what happens when a table moves from one AM to another (drop unsupported settings, or rewrite them for the new method). That matters for extension authors building alternative storage engines, who need a clean way to expose AM-specific knobs without pretending every table is a heap.

Andrew Dunstan has been carrying the patch set through review for EDB. Reviewers have already forced fixes for real failures: VACUUM could crash when an AM’s option blob was smaller than the heap layout and toast needed standard parameters; mixed SET ACCESS METHOD / SET / RESET in one statement could reject a valid final state depending on clause order; and pg_dump’s --no-table-access-method path could emit dumps that failed to restore, losing table and data, because AM-only options were tied to CREATE. The planned dump behavior keeps standard options on CREATE and moves AM-specific ones to a separate ALTER that the flag can skip, which in turn pushes AMs to inherit the usual option names rather than reinvent them.

Aleksander Alekseev noted a related wish: letting ordinary extensions add CREATE TABLE WITH options without implementing a table AM. Dunstan treated that as separate scope and declined to block this work on it.

Open points remain. Documentation must warn that a no-access-method dump restores cleanly only if the default AM accepts every standard option present on the dumped tables. A locking gap also surfaced: Alter Table can choose a lock level before the AM library is loaded, so an option that should demand a strong lock may run under a weaker one until the extension is present; a conservative fix is under discussion so unknown option names take a strong lock. Index and some toast paths still assume the heap scan routine, limiting how far dummy test AMs can go without reimplementing heap behavior.

The feature is not committed. It is the kind of plumbing custom table AMs have needed if PostgreSQL’s pluggable storage story is to grow beyond heap-shaped parameters.