Re: Review: Patch to compute Max LSN of Data Pages

On Sat, Sep 14, 2013 at 3:03 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>On Monday, July 08, 2013 5:16 PM Andres Freund wrote:
>>>On 2013-07-08 17:10:43 +0530, Amit Kapila wrote:
>>>> On Monday, July 08, 2013 4:26 PM Andres Freund wrote:
>>>> > On 2013-07-08 16:17:54 +0530, Hari Babu wrote:
>>>> > > + This utility can also be used to decide whether backup is
>>>> > required or not when the data page
>>>> > > + in old-master precedes the last applied LSN in old-standby
>>>> > (i.e., new-master) at the
>>>> > > + moment of the failover.
>>>> > > + </para>
>>>> > > + </refsect1>
>>>> >
>>>> > I don't think this is safe in any interesting set of cases. Am I
>>>> > missing
>>>> > something?
>>>>
>>>> No, you are not missing anything. It can be only used to find max LSN in
>>>> database which can avoid further corruption
>
>>>Why is the patch submitted documenting it as a use-case then? I find it
>>>rather scary if the *patch authors* document a known unsafe use case as
>>>one of the known use-cases.
>
>>I got the problem which can occur with the specified use case. Removed the
>>wrong use case specified above.
>>Thanks for the review, please find the updated patch attached in the mail.
>
> Patch is not getting compiled on Windows, I had made following changes:
> a. updated the patch for resolving Windows build
> b. few documentation changes in (pg_resetxlog.sgml) for spelling
> mistake and minor line change
> c. corrected year for Copyright in file pg_computemaxlsn.c

I am OK with this patch in its current form, modulo some grammar
issues in the documentation which I can fix before committing.
However, I'm unclear whether there was sufficient consensus to proceed
with this. Can others weigh in? If there is too much residual
unhappiness with this, then we should just mark this as Rejected and
stop wasting time on it; it can be pushed to PGXN or similar even if
we don't put it in core.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company