Re: Full page images in WAL & Cache Invalidation - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: Full page images in WAL & Cache Invalidation
Date
Msg-id 46A39AAD.6000602@phlo.org
Whole thread Raw
In response to Re: Full page images in WAL & Cache Invalidation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Full page images in WAL & Cache Invalidation  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Full page images in WAL & Cache Invalidation  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.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.

I still don't fully understand if and what problems are caused by overly 
aggresive cache flushing - what puzzles me is that DDL statements seems
to be considered something rare on a production system by most people on
this list, yet the caches seem to be highly optimized to avoid 
unnecessary invalidates.

Leaving aside the btree issues, are you worried about performance
problems, or can aggressive cache flushing hurt correctness?

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...

greetings, Florian Pflug


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 8.2 is 30% better in pgbench than 8.3
Next
From: Tom Lane
Date:
Subject: Re: Full page images in WAL & Cache Invalidation