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
