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 548C52D7.2000204@dalibo.com
Whole thread Raw
In response to Re: [TODO] Track number of files ready to be archived in pg_stat_archiver  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [TODO] Track number of files ready to be archived in pg_stat_archiver  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 18/11/2014 08:36, Michael Paquier a écrit :
> On Wed, Oct 22, 2014 at 12:50 AM, Brightwell, Adam 
> <adam.brightwell@crunchydatasolutions.com> wrote:
>> Though, I would think that the general desire would be to keep
>> the patch relevant ONLY to the necessary changes.  I would not
>> qualify making those types of changes as relevant, IMHO.  I do
>> think this is potential for cleanup, however, I would suspect
>> that would be best done in a separate patch.  But again, I'd
>> defer to a committer whether such changes are even 
>> necessary/acceptable.
> 
> I have been looking at this patch, and I think that it is a mistake
> to count the .ready files present in archive_status when calling 
> pg_stat_get_archiver(). If there are many files waiting to be 
> archived, this penalizes the run time of this function, and the 
> application behind relying on those results, not to mention that 
> actually the loop used to count the .ready files is a copy of what
> is in pgarch.c. Hence I think that we should simply count them in 
> pgarch_readyXlog, and then return a value back to 
> pgarch_ArchiverCopyLoop, value that could be decremented by 1 each 
> time a file is successfully archived to keep the stats as precise
> as possible, and let the information know useful information when 
> archiver process is within a single loop process of 
> pgarch_ArchiverCopyLoop. This way, we just need to extend 
> PgStat_MsgArchiver with a new counter to track this number.
> 
> The attached patch, based on v2 sent previously, does so.
> Thoughts?
> 
> 
> 
> 

Sorry for this late answer.

I agree with you about the problems of the v2 patch I originally sent.
I think this v3 is the right way of keeping track of .ready files, so
it's ok for me. The v3 also still applies well on current head.


Regards.
- -- 
Julien Rouhaud
http://dalibo.com - http://dalibo.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJUjFLWAAoJELGaJ8vfEpOqV9AIAI1yTUYqiB8rMJpfM47IHiM6
92fRNJ7sGwuFKD7Vb2gcMuRLelhFVRevJ7tjhggci8Y36j6YDXgqz74kTjkXvcjN
/SlyS2CIcSleWwvJ2A/WZM0rIzbtm1DTahKupQQ8UdcjHsk3m8T+nySIGyQWdKzz
X9JiXATztlevAaC/1Mf+zsbDSzW5tiQVfIm835G1/sEqIXh43TQyyXyr/nJFlFfQ
85OPssInrxt1e2F82s3SoXb7lIBZg77fZTEusxG5zHX5ANF6uMpF7CBJiZXezRYw
xWrKKuJBLw4zSimzNsVYpxNN3jJuANEAkvzIV+glKDYD57A3DbmpYSJ+btXtDIw=
=JKhg
-----END PGP SIGNATURE-----



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Custom timestamp format in logs
Next
From: Michael Paquier
Date:
Subject: Status of CF 2014-10 and upcoming 2014-12