Re: Some other things about contrib/bloom and generic_xlog.c
От | Tom Lane |
---|---|
Тема | Re: Some other things about contrib/bloom and generic_xlog.c |
Дата | |
Msg-id | 18571.1460420479@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Some other things about contrib/bloom and generic_xlog.c (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Some other things about contrib/bloom and generic_xlog.c
Re: Some other things about contrib/bloom and generic_xlog.c |
Список | pgsql-hackers |
Michael Paquier <michael.paquier@gmail.com> writes: > As given out now, we are able to do the following: > - Log a full page > - Log a delta of a full page, which is actually data associated to a page. > - At recovery, replay those full pages with a delta. Right. > 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. 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. 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. 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. regards, tom lane
В списке pgsql-hackers по дате отправления: