Re: [TODO] Track number of files ready to be archived in pg_stat_archiver

From: Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "Brightwell, Adam" <adam(dot)brightwell(at)crunchydatasolutions(dot)com>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, Gilles Darold <gilles(dot)darold(at)dalibo(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [TODO] Track number of files ready to be archived in pg_stat_archiver
Date: 2014-12-13 14:53:11
Message-ID: 548C52D7.2000204@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)brightwell(at)crunchydatasolutions(dot)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-----

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-12-13 15:00:21 Status of CF 2014-10 and upcoming 2014-12
Previous Message Michael Paquier 2014-12-13 14:50:44 Custom timestamp format in logs