To: Simon Riggs <simon@2ndQuadrant.com>
cc: Robert Haas <robertmhaas@gmail.com>, Florian Pflug <fgp@phlo.org>,
	Aidan Van Dyk <aidan@highrise.ca>, Daniel Farina <daniel@heroku.com>,
	Chris Redekop <chris@replicon.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Hot Backup with rsync fails at pg_clog if under load 
In-reply-to: 
 <CA+U5nMLBnRU_KJCrMME5eRG930E=k65yFbj6R+1LXMtZ7nippw@mail.gmail.com>
References: 
 <CAC2SuRJTtsXL67EuTdd25GThYZBZTcepfG7Z0Vvv2pZQWzJD=w@mail.gmail.com>
	<CAC2SuRKyt0K35ExCTNnYuf+3XfAjSJJQV_sVX+O4jVTfDuAxog@mail.gmail.com>
	<CAC2SuRJPNqPe7Ga8LT6Q-vOgn05BmiH=y6F_dfiVu5u3NfOs=w@mail.gmail.com>
	<CAAZKuFbUSxOb8x80k9-fD9CsXBRmzTNWutqcDVGaTvwFTvURiQ@mail.gmail.com>
	<213AEFBF-479C-4F9E-B0CA-24AAB2C9F4DD@phlo.org>
	<CA+U5nMJksETN=sJEmu2FqhWNv2Uv63e_9T5OrZEGmviNnWEC5Q@mail.gmail.com>
	<CA+U5nMJfnaay7p_rRzrvWLTyO-aKNEh414czr3jyXT8vhHiJVw@mail.gmail.com>
	<1A94CE1A-C3E5-4923-B677-623D41BC273F@phlo.org>
	<CA+U5nMKUUoA8kRG=itfsO5nZuE3x_KDJz78EaUN3_FKmq-uMJA@mail.gmail.com>
	<6C3D7EDA-573E-46DC-9047-5FEB92876DA8@phlo.org>
	<CA+U5nMJLDZ7VP1O3Jdde+p+9-HxuEi8qG+v5+LuoZGSiOvhkxA@mail.gmail.com>
	<CAC_2qU_eCUYMY6O5CgAK0pYugd=moApirdAt8G_G2sYKs0DfOQ@mail.gmail.com>
	<CA+U5nML+fJgz-NdZrGX+R3m6JKnT1JC=v0iXkkSAsojnsqqPoQ@mail.gmail.com>
	<FD57812A-6A9B-44F3-8CDF-3CD2F8D9918E@phlo.org>
	<12E895D5-C6D0-4E71-B9C3-85E1BC14E6B8@phlo.org>
	<CA+TgmoaJw9TV8CTP0t9R62=JFUb5ye811Wm4sK1M=3LOb!
	+PYsA@mail.gmail.com> <18333.1{ h@
	<CA+U5nMLBnRU_KJCrMME5eRG930E=k65yFbj6R+1LXMtZ7nippw@mail.gmail.com>
Comments: In-reply-to Simon Riggs <simon@2ndQuadrant.com>
	message dated "Thu, 27 Oct 2011 14:36:54 +0100"
Date: Thu, 27 Oct 2011 10:13:13 -0400
Message-ID: <27827.1319724793@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Simon Riggs <simon@2ndQuadrant.com> writes:
> On Thu, Oct 27, 2011 at 12:36 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, Oct 27, 2011 at 5:37 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> It's much easier to understand that StartupCLOG() is actually a no-op
>>> and that we need to trim the clog at the end of recovery in all cases.

>> If it's a no-op, why have it at all?

> It is a no-op for exactly the same reason other similar functions are
> no-ops - it used to do something but now does not.

> Anyone seeing StartupSubtrans and StartupMultiXact but no StartupClog
> will immediately ask "why?".

I think it's a good point that StartupCLog doesn't exist in a vacuum
but should be parallel to the init functions for the other SLRU modules.
So at this point I think I agree with Simon's approach.  However, the
obvious next question is whether those other modules don't need to be
changed also, and if not why not.

Another issue is that if StartupCLog is left as a no-op, what will
happen if someone mistakenly tries to access clog before the trim
function is called?  It would be a good idea to make sure that such
a thing results in an easily-identifiable failure.

			regards, tom lane