Re: Full page images in WAL & Cache Invalidation

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Full page images in WAL & Cache Invalidation
Date: 2007-07-22 22:07:25
Message-ID: 1185142045.4284.79.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 2007-07-22 at 19:58 +0200, Florian G. Pflug wrote:
> Tom Lane wrote:
> > "Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
> >> I'm currently working on correctly flushing the
> >> catalog/relation/sgmr caches on a readonly PITR
> >> slave during recovery.
> >
> > I don't believe there is any workable solution to that short of logging
> > cache-flush operations in WAL.

> The reason that I dislike WAL-logging of the flush operations so much is
> that it since peopel are concerned about the amount of wal traffic
> postgres generated, such a solution would introduce yet another GUC.
> And to make this reasonable foolproof, the slave would need a way to
> detect if that GUC is set correctly on the master. All in all, that
> seems to be quite hackish...

Seems like we should WAL log flush operations first. It's fairly
straightforward to do that and we can then measure its effect on the
primary easily enough. Your other suggestions seem much more complex.

I think we have a reasonable tolerance for increases in WAL and as you
said earlier, we may balance that out with other optimisations. Or we
may find a more efficient way of doing it later.

Let's aim to get that first query running, then go back and tune it
later.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2007-07-22 22:30:22 Re: Full page images in WAL & Cache Invalidation
Previous Message Tom Lane 2007-07-22 21:42:14 Re: Full page images in WAL & Cache Invalidation