Subject: Re: Updating FSM on recovery
From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
In-Reply-To: <7992.1225210576@sss.pgh.pa.us>
References: <49072021.7010801@enterprisedb.com>
	<1225208150.3971.191.camel@ebony.2ndQuadrant>
	<1225209751.3971.196.camel@ebony.2ndQuadrant>
	<7992.1225210576@sss.pgh.pa.us>
Content-Type: text/plain
Date: Tue, 28 Oct 2008 16:45:14 +0000
Message-Id: <1225212314.3971.206.camel@ebony.2ndQuadrant>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


On Tue, 2008-10-28 at 12:16 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > Or possibly an XLogInsertDeferred() which just queues up some work so
> > the next time we call XLogInsert() it will insert the deferred work as
> > well as the main work all in one lock cycle. It would only be usable for
> > low priority info like FSM stuff that isn't needed for recovery. Maybe
> > we could do that with hints also.
> 
> If it isn't needed for recovery, why would we be logging it at all?

You just agreed that the info didn't need to be very accurate. There's a
few things on the server that aren't needed for recovery, but it might
be useful if they were logged occasionally to give roughly correct
values.

Contention on WALInsertLock seems to be a problem, yet writing WAL to
disk is not a bottleneck. Deferring writing it slightly to allow things
to be batched might be one way of smoothing the impact of that type of
operation. That might be better than a heuristic method of reducing the
number of inserts.

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support