Re: [TODO] Track number of files ready to be archived in pg_stat_archiver - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: [TODO] Track number of files ready to be archived in pg_stat_archiver
Date
Msg-id CAOBaU_YiLuQ+me+tk1ehK9rPp6B7WJhCN-utQNvt_2ekq_Y9uw@mail.gmail.com
Whole thread Raw
In response to Re: [TODO] Track number of files ready to be archived in pg_stat_archiver  ("Brightwell, Adam" <adam.brightwell@crunchydatasolutions.com>)
Responses Re: [TODO] Track number of files ready to be archived in pg_stat_archiver
List pgsql-hackers
On Tue, Oct 21, 2014 at 7:35 AM, Brightwell, Adam <adam.brightwell@crunchydatasolutions.com> wrote:
Julien,

The following is an initial review:


Thanks for the review.
 
* Applies cleanly to master (f330a6d).
* Regression tests updated and pass, including 'check-world'.
* Documentation updated and builds successfully.
* Might want to consider replacing the following magic number with a constant or perhaps calculated value.

+       int         basenamelen = (int) strlen(rlde->d_name) - 6;

* Wouldn't it be easier, or perhaps more reliable to use "strrchr()" with the following instead?

+           strcmp(rlde->d_name + basenamelen, ".ready") == 0)

char *extension = strrchr(ride->d_name, '.');
...
strcmp(extension, ".ready") == 0)

I think this approach might also help to resolve the magic number above.  For example:

char *extension = strrchr(ride->d_name, '.');
int basenamelen = (int) strlen(ride->d_name) - strlen(extension);


Actually, I used the same loop as the archiver one (see backend/postmaster/pgarch.c, function pgarch_readyXlog) to get the exact same number of files.

If we change it in this patch, it would be better to change it everywhere. What do you think ?

-Adam

--

pgsql-hackers by date:

Previous
From: Marti Raudsepp
Date:
Subject: Re: [PATCH] Simplify EXISTS subqueries containing LIMIT
Next
From: Florian Pflug
Date:
Subject: Re: Patch: Add launchd Support