Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader
Date
Msg-id 50A51076.90004@vmware.com
Whole thread Raw
In response to Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 15.11.2012 16:50, Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
>> On 15.11.2012 03:17, Andres Freund wrote:
>>>
>>> Features:
>>> - streaming reading/writing
>>> - filtering
>>> - reassembly of records
>>>
>>> Reusing the ReadRecord infrastructure in situations where the code that wants
>>> to do so is not tightly integrated into xlog.c is rather hard and would require
>>> changes to rather integral parts of the recovery code which doesn't seem to be
>>> a good idea.
>>>
>>> Missing:
>>> - "compressing" the stream when removing uninteresting records
>>> - writing out correct CRCs
>>> - separating reader/writer
>>
>> I'm disappointed to see that there has been no progress on this
>> patch since last commitfest. I thought we agreed on the approach I
>> championed for here:
>> http://archives.postgresql.org/pgsql-hackers/2012-09/msg00636.php.
>> There wasn't much work left to finish that, I believe.
>>
>> Are you going to continue working on this?
>
> I worked a bit more on that patch of yours, but I neglected to submit
> it.  Did you have something in particular that you wanted changed in it?

Off the top of my head, there were a two open items with the patch as I 
submitted it:

1. Need to make sure it's easy to compile outside backend code. So that 
it's suitable for using in an xlogdump contrib module, for example.

2. do something about error reporting. In particular, xlogreader.c 
should not call emode_for_corrupt_record(), but we need to provide for 
that functionlity somehow. I think I'd prefer xlogreader.c to not 
ereport() on a corrupt record. Instead, it would return an error string 
to the caller, which could then decide what to do with it. Translating 
the messages needs some thought, though.

Other than those, and cleanup of any obsoleted comments etc. and adding 
docs, I think it was good to go.

- Heikki



pgsql-hackers by date:

Previous
From: Will Crawford
Date:
Subject: Re: [PATCH] binary heap implementation
Next
From: Merlin Moncure
Date:
Subject: Re: WIP patch for hint bit i/o mitigation