On Mon, Apr 11, 2016 at 11:29 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paqu...@gmail.com> writes: >> Actually, as I look at this code for the first time, I find that >> GenericXLogFinish() is a very confusing interface. It makes no >> distinction between a page and the meta data associated to this page, >> this is controlled by a flag isNew and buffer data is saved as some >> delta. Actually, fullmage is not exactly true, this may refer to a >> page that has a hole. It seems to me that we should not have one but >> two routines: GenericXLogRegisterBuffer and >> GenericXLogRegisterBufData, similar to what the normal XLOG routines >> offer. > > Hmm. Maybe the documentation leaves something to be desired, but > I thought that the interface was reasonable if you grant that the > goal is to be easy to use rather than to have maximum performance. > The calling code only has to concern itself with making the actual > changes to the target pages, not with constructing WAL descriptions > of those changes. Also, the fact that the changes don't have to be > made within a critical section is a bigger help than it might sound. > > So I don't really have any problems with the API as such. I tried > to improve the docs a day or two ago, but maybe that needs further > work.
Well, I am not saying that the given interface does nothing, far from that. Though I think that we could take advantage of the rmgr RM_GENERIC_ID introduced by this interface to be able to generate custom WAL records and pass them through a stream. 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. 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 The first 3 ones are done via the set of routines generating WAL records for the rmgr RM_GENERIC_ID. The 4th one needs a hook in generic_redo. Looking at the thread where this patch has been debated I am not seeing a discussion regarding that. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers