Re: Review: Patch to compute Max LSN of Data Pages - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Review: Patch to compute Max LSN of Data Pages
Date
Msg-id CA+TgmoYuWx6__irD6c=-HxnK-h1w_X+2mzRVWJh4RCaMUtfHjQ@mail.gmail.com
Whole thread Raw
In response to Re: Review: Patch to compute Max LSN of Data Pages  (Amit kapila <amit.kapila@huawei.com>)
Responses Re: Review: Patch to compute Max LSN of Data Pages
List pgsql-hackers
On Wed, Jul 3, 2013 at 8:44 AM, Amit Kapila <amit.kapila@huawei.com> wrote:
>> Why does this patch need all of this fancy path-handling logic -
>> specifically, remove_parent_refernces() and make_absolute_path()?
>> Surely its needs are not that different from pg_ctl or pg_resetxlog or
>> pg_controldata.  If they all need it and it's duplicated, we should
>> fix that.  Otherwise, why the special logic here?
>>
>> I don't think we need getLinkPath() either.  The server has no trouble
>> finding its files by just using a pathname that follows the symlink.
>> Why do we need anything different here?  The whole point of symlinks
>> is that you can traverse them transparently, without knowing where
>> they point.
>
> It is to handle negative scenario's like if there is any recursion in path.
> However if you feel this is not important, it can be removed.

I'm having a hard time imagining a situation where that would be a
problem.  If the symlink points to itself somehow, the OS will throw
an error.  If your filesystem is so badly hosed that the directory
structure is more fundamentally broken than the OS's circular-symlink
detection code can handle, whether or not this utility works is a
second-order consideration.  What kind of scenario are you imagining?

>> I think it would be a good idea to have a mode that prints out the max
>> LSN found in *each data file* scanned, and then prints out the overall
>> max found at the end.  In fact, I think that should perhaps be the
>> default mode, with -q, --quiet to disable it.
>
> Printing too many LSN for each file might fill user's screen and he might be
> needing only overall LSN.
> Should we keep -p --printall as option to print all LSN's and keep default
> as overall max LSN?

Honestly, I have a hard time imagining the use case for that mode.
This isn't a tool that people should be running regularly, and some
output that lends a bit of confidence that the tool is doing the right
thing seems like a good thing.  Keep in mind it's likely to run for
quite a while, too, and this would provide a progress indicator.  I'll
defer to whatever the consensus is here but my gut feeling is that if
you don't want that extra output, there's a good chance you're
misusing the tool.

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



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Next
From: Amit Kapila
Date:
Subject: Re: Move unused buffers to freelist