Re: WAL format and API changes (9.5)

On 05/17/2014 02:54 PM, Heikki Linnakangas wrote:
> On 04/03/2014 06:37 PM, Tom Lane wrote:
>>>> Let's simplify that, and have one new function, XLogOpenBuffer, which
>>>> returns a return code that indicates which of the four cases we're
>>>> dealing with. A typical redo function looks like this:
>>>>     if (XLogOpenBuffer(0, &buffer) == BLK_REPLAY)
>>>>     {
>>>>         /* Modify the page */
>>>>         ...
>>>>         PageSetLSN(page, lsn);
>>>>         MarkBufferDirty(buffer);
>>>>     }
>>>>     if (BufferIsValid(buffer))
>>>>         UnlockReleaseBuffer(buffer);
>>>> The '0' in the XLogOpenBuffer call is the ID of the block reference
>>>> specified in the XLogRegisterBuffer call, when the WAL record was created.
>> +1, but one important step here is finding the data to be replayed.
>> That is, a large part of the complexity of replay routines has to do
>> with figuring out which parts of the WAL record were elided due to
>> full-page-images, and locating the remaining parts.  What can we do
>> to make that simpler?
>>
>> Ideally, if XLogOpenBuffer (bad name BTW) returns BLK_REPLAY, it would
>> also calculate and hand back the address/size of the logged data that
>> had been pointed to by the associated XLogRecData chain item.  The
>> trouble here is that there might've been multiple XLogRecData items
>> pointing to the same buffer.  Perhaps the magic ID number you give to
>> XLogOpenBuffer should be thought of as identifying an XLogRecData chain
>> item, not so much a buffer?  It's fairly easy to see what to do when
>> there's just one chain item per buffer, but I'm not sure what to do
>> if there's more than one.
>
> Ok, I wrote the first version of a patch for this.

Here's a new version, rebased against master. No other changes.

- Heikki