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

> -----Original Message-----
> From: Robert Haas [mailto:robertmhaas@gmail.com]
> Sent: Wednesday, July 03, 2013 6:40 PM
> To: Amit Kapila
> Cc: Andres Freund; Josh Berkus; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Review: Patch to compute Max LSN of Data Pages
> 
> 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?


amit@linux:~> md test 
amit@linux:~> cd test 
amit@linux:~/test> ln -s ~/test link_test 
amit@linux:~/test> ls 
link_test 
amit@linux:~/test> cd link_test 
amit@linux:~/test/link_test> ls 
link_test 
amit@linux:~/test/link_test> cd link_test 
amit@linux:~/test/link_test/link_test> cd link_test 
amit@linux:~/test/link_test/link_test/link_test> pwd 
/home/amit/test/link_test/link_test/link_test 
amit@linux:~/test/link_test/link_test/link_test>

Platform details
----------------
Suse - 11.2
Kernel - 3.0.13

This is to avoid when user has given some path where db files are present.

> >> 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.

With Regards,
Amit Kapila.