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

From: Amit kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Muhammad Usama'" <m(dot)usama(at)gmail(dot)com>
Cc: "'Robert Haas'" <robertmhaas(at)gmail(dot)com>, "'Alvaro Herrera'" <alvherre(at)2ndquadrant(dot)com>, "'Fujii Masao'" <masao(dot)fujii(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: Patch to compute Max LSN of Data Pages
Date: 2012-12-03 13:56:02
Message-ID: 6C0B27F7206C9E4CA54AE035729E9C383BEA0B08@szxeml509-mbx
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>I think we should expect provided path to be relative to current directory
> or may consider it to be relative to either one of Data or CWD.
>Because normally we expect path to be relative to CWD if some program is
> asking for path in command line.

Please find the attached patch to make the path relative to CWD and check if the path is under data directory.

Now the only point raised by Alvaro and you for this patch which is not yet addressed is :

> 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.
> 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.
I am just not sure whether we should handle this functionality and if we have to handle what is better way to provide it to user.
Shall we provide new option -r or something for it.

Opinions/Suggestions?

IMHO, such functionality can be easily extendable in future.
However I have no problem in implementing such functionality if you are of opinion that this is basic and it should go with first version of feature.

With Regards,
Amit Kapila.

Attachment Content-Type Size
pg_computemaxlsn_v3.patch application/octet-stream 26.9 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-12-03 14:03:33 Re: [v9.3] OAT_POST_ALTER object access hooks
Previous Message Dimitri Fontaine 2012-12-03 13:53:50 Re: Refactoring standby mode logic