Re: Extensible Rmgr for Table AMs

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Extensible Rmgr for Table AMs
Дата
Msg-id 8a1b1ab033342433b1f827fee04ee562231fdb80.camel@j-davis.com
обсуждение исходный текст
Ответ на Extensible Rmgr for Table AMs  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Extensible Rmgr for Table AMs  (Julien Rouhaud <rjuju123@gmail.com>)
Список 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


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Следующее
От: Zhihong Yu
Дата:
Сообщение: Re: Partial aggregates pushdown