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

From Amit Kapila
Subject Re: Review: Patch to compute Max LSN of Data Pages
Date
Msg-id 000f01cdcd2c$4ff05ce0$efd116a0$@kapila@huawei.com
Whole thread Raw
In response to Re: Review: Patch to compute Max LSN of Data Pages  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Wednesday, November 28, 2012 3:36 AM Alvaro Herrera wrote:
> Amit Kapila escribió:
> >
> > Friday, November 23, 2012 5:38 AM Muhammad Usama wrote:
>
> > >- I think when finding the max LSN of single file the utility should
> > > consider all relation segments.
> >   Would you like to find for all relation related segments:
> >   Like 12345, 12345.1 ... 12345.n    Or
> >   12345, 12345.1 ... and 12345_vm, 12345.1_vm
> >
> >   But how about if user asks for 12345.4, do we need to find all
> greater
> > than 12345.4?
> >
> >   IMHO, as this utility is not aware of relation or any other logical
> >   entity and deals with only file or directory, it is okay to find
> >   only for that file.
>
> Hmm.  I think I'd expect that if I give pg_computemaxlsn a number, it
> should consider that it is a relfilenode, and so it should get a list of
> all segments for all forks of it.  So if I give "12345" it should get
> 12345, 12345.1 and so on, and also 12345_vm 12345_vm.1 and so on.

Yes, I think this can be done either by having it as new option or
internally code can interpret as you suggest.
Also, can't we think of it as an extended usecase and implement it on top of
base, if this usecase is not an urgent?

> However, if what I give it is a path, i.e. it contains a slash, I think
> it should only consider the specific file mentioned.  In that light, I'm
> not sure that command line options chosen are the best set.

Yes for sure command line options can be improved/extended based on usecase.
Please feel free to give suggestion regarding command line option if you
feel current option
is not an extendable option.

One way is -p should be for file path and may be -r for relfile number.

With Regards,
Amit Kapila.




pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Further pg_upgrade analysis for many tables
Next
From: Pavel Stehule
Date:
Subject: Re: MySQL search query is not executing in Postgres DB