Re: Extensible Rmgr for Table AMs - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Extensible Rmgr for Table AMs
Date
Msg-id CA+TgmoZ9xRUP4vLW+trZ1_FT6G6ER_PNEtF21AL6Mvrei=h+3Q@mail.gmail.com
Whole thread Raw
In response to Extensible Rmgr for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Mon, Nov 8, 2021 at 6:36 PM Jeff Davis <pgsql@j-davis.com> wrote:
> Extensible rmgr would enable the table AM to support its own
> redo/decode hooks and WAL format, so that it could support crash
> recovery, physical replication, and logical replication.

Without taking a position on your implementation, which I have not
studied, I like this idea in concept and I think it's an important
goal.

> Are there any other major arguments/objections that I missed?

ISTR some discussion of the fact that uninstalling the extension that
uses this facility, or failing to install it on your standby, will
lead to an unusable database. Personally, I don't see that as a big
problem: we should just document that if you choose to use an
extension like this, then (1) it needs to be installed on all standbys
and (2) if you ever want to get rid of it, you need to stop using it,
drop all the objects created with it, and then wait until all the WAL
previously generated by that extension is gone not only from pg_wal
but from any archived WAL files or backups that you intend to use with
that cluster before you actually nuke it. Users who don't want to
abide by those restrictions need not install such extensions. Users
who don't read the documentation might end up sad, but it doesn't seem
particularly likely, and it's hardly the only part of the
documentation that users shouldn't ignore.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Removed unused import modules from tap tests
Next
From: Robert Haas
Date:
Subject: Re: should we enable log_checkpoints out of the box?