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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Review: Patch to compute Max LSN of Data Pages
Date: 2013-07-03 13:10:17
Message-ID: CA+TgmoYuWx6__irD6c=-HxnK-h1w_X+2mzRVWJh4RCaMUtfHjQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 3, 2013 at 8:44 AM, Amit Kapila <amit(dot)kapila(at)huawei(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2013-07-03 13:11:28 Re: Move unused buffers to freelist
Previous Message Simon Riggs 2013-07-03 12:59:15 Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])