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

From Jeff Davis
Subject Re: Extensible Rmgr for Table AMs
Date
Msg-id 8a1b1ab033342433b1f827fee04ee562231fdb80.camel@j-davis.com
Whole thread Raw
In response to Extensible Rmgr for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Extensible Rmgr for Table AMs
List pgsql-hackers
On Mon, 2021-11-08 at 15:36 -0800, Jeff Davis wrote:
> The attached patch (against v14, so it's easier to test columnar) is
> somewhat like a simplified version of [3] combined with refactoring
> to
> make decoding a part of the rmgr.

New patches attached (v3). Essentially the content as v2, but split
into 3 patches and rebased.

Review on patch 0001 would be helpful. It makes decoding just another
method of rmgr, which makes a lot of sense to me from a code
organization standpoint regardless of the other patches. Is there any
reason not to do that?

The other patches then make rmgr extensible, which in turn makes
decoding extensible and solves the logical replication problem for
custom table AMs. The most obvious way to make rmgr extensible would be
to expand the rmgr table, but I was concerned about making that dynamic
(right now the structure is entirely constant and perhaps that's
important for some optimizations?). So, at the cost of complexity I
made a separate, dynamic rmgr table to hold the custom entries.

The custom rmgr API would probably be marked "experimental" for a
while, and I don't expect lots of people to use it given the challenges
of a production-quality table AM. But it's still important, because
without it a table AM has no chance to participate in logical
replication.

Regards,
    Jeff Davis


Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Next
From: Zhihong Yu
Date:
Subject: Re: Partial aggregates pushdown