Re: Some other things about contrib/bloom and generic_xlog.c

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Some other things about contrib/bloom and generic_xlog.c
Дата
Msg-id CAB7nPqQruy22hBHhOFpU3tYgmRgmk7YxZo6WVUqTOSocNUGnZg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Some other things about contrib/bloom and generic_xlog.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Some other things about contrib/bloom and generic_xlog.c  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
On Tue, Apr 12, 2016 at 9:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> What I thought we should be able to do with that should not be only
>> limited to indexes, aka to:
>> - Be able to register and log full pages
>> - Be able to log data associated to a block
>> - Be able to have record data
>> - Use at recovery custom routines to apply those WAL records
>
> I'm not following your distinction between a "page" and a "block",
> perhaps.

s/block/page/. Sorry for the confusion.

> Also, the entire point here is that extensions DON'T
> get to have custom apply routines, because we have no way for
> replay to know about such apply routines.  (It surely cannot look
> in the catalogs for them, but there's no other suitable infrastructure
> either.)  In turn, that means there's little value in having any custom
> data associated with the WAL records.

Well, yes, the startup process has no knowledge of that. That's why it
would need to go through a hook, but the startup process has no
knowledge of routines loaded via _PG_init perhaps? I recall that it
loaded them. The weakness with this interface is that one needs to be
sure that this hook is actually loaded properly.

> If we ever solve the registering-custom-replay-routines conundrum,
> it'll be time to think about what the frontend API for that ought
> to be.  But this patch is not pretending to solve that, and indeed is
> mainly showing that it's possible to have a useful WAL extension API
> that doesn't require solving it.

Yep. I am not saying the contrary. This patch solves its own category
of things with its strict page-level control.

> In any case, the existence of this API doesn't foreclose adding
> other APIs (perhaps backed by other RM_GENERIC_ID WAL record types)
> later on.  So I don't think we need to insist that it do everything
> anyone will ever want.

Perhaps I am just confused by the interface. Linking the idea of a
page delta with GenericXLogRegister is not that intuitive, knowing
that what it should actually be GenericXLogRegisterBuffer and we
should have GenericXLogAddDelta, that applies a page difference on top
of an existing one.
-- 
Michael



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Some other things about contrib/bloom and generic_xlog.c
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Some other things about contrib/bloom and generic_xlog.c