Re: Logical insert/update/delete WAL records for custom table AMs

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Logical insert/update/delete WAL records for custom table AMs
Дата
Msg-id CAA4eK1+5TDcWVNLp1uDAw-R3c8f5zJQu+YDjSoAWEg_hpeHCBQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Logical insert/update/delete WAL records for custom table AMs  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Logical insert/update/delete WAL records for custom table AMs  (Simon Riggs <simon.riggs@enterprisedb.com>)
Список pgsql-hackers
On Tue, Nov 9, 2021 at 5:12 AM Jeff Davis <pgsql@j-davis.com> wrote:
>
> On Fri, 2021-11-05 at 10:00 +0530, Amit Kapila wrote:
> > I am not talking about decoding plugin but rather decoding itself,
> > basically, the work we do in reorderbuffer.c, decode.c, etc. The two
> > things I remember were tuple format and transaction ids as mentioned
> > in my previous email.
>
> If it's difficult to come up with something that will work for all
> table AMs, then it suggests that we might want to go towards fully
> extensible rmgr, and have a decoding method in the rmgr.
>
> I started a thread (with a patch) here:
>
>
> https://postgr.es/m/ed1fb2e22d15d3563ae0eb610f7b61bb15999c0a.camel@j-davis.com
>
> > I think we should try to find a solution for
> > tuple format as the current decoding code relies on it if we want
> > decoding to deal with another table AMs transparently.
>
> Agreed, but it seems like we need basic extensibility first. For now,
> we'll need to convert to a heap tuple,
>

Okay, but that might have a cost because we need to convert it before
WAL logging it, and then we probably also need to convert back to the
original table AM format during recovery/standby apply.

-- 
With Regards,
Amit Kapila.



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

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Frontend error logging style
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Removed unused import modules from tap tests