pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Updating FSM on recovery
Date: Tue, 28 Oct 2008 16:45:14 +0000
Message-ID: <1225212314.3971.206.camel@ebony.2ndQuadrant> (raw)
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>


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




view thread (16+ messages)  latest in thread

Message-ID: <1225212314.3971.206.camel@ebony.2ndQuadrant>
Permalink:  ../1225212314.3971.206.camel@ebony.2ndQuadrant/
Also on:    postgresql.org/message-id/1225212314.3971.206.camel@ebony.2ndQuadrant

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: simon@2ndQuadrant.com, tgl@sss.pgh.pa.us, heikki.linnakangas@enterprisedb.com
  Subject: Re: Updating FSM on recovery
  In-Reply-To: <1225212314.3971.206.camel@ebony.2ndQuadrant>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox