Backup & restore

xpatch tables go through pg_dump and pg_restore like any other table. The dump carries the row data, the internal _xp_seq values, and each table's configuration. There are exactly two things to get right: the target server needs the extension, and you run one fixup after the restore.

What ends up in the dump

• Row data and _xp_seq. The internal _xp_seq values are dumped and restored too, so every version keeps its original sequence number and the restored table rebuilds the same version chains.
• Per-table config. The xpatch.table_config catalog is registered to be dumped with the extension, so your group_by, order_by, and compression settings travel with the data.

No special flags. A normal dump captures everything:

pg_dump -Fc mydb > mydb.dump

Restoring

# on the target, then in the target databasepsql -d newdb -c "CREATE EXTENSION IF NOT EXISTS pg_xpatch;"

pg_restore -d newdb mydb.dump

SELECT xpatch.fix_restored_configs();

Moving config between databases

If you want the configuration on its own, for a migration script or to reapply it elsewhere, dump_configs() emits ready-to-run configure() statements:

SELECT * FROM xpatch.dump_configs();-- SELECT xpatch.configure('public.documents', group_by => 'doc_id', ...);-- SELECT xpatch.configure('public.notes', ...);

Run that output against the target after loading the tables. This is the portable alternative when a plain catalog round-trip is not what you want.