Skip site navigation (1) Skip section navigation (2)

Re: Block-level CRC checks

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>,Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>,Brian Hurt <bhurt(at)janestcapital(dot)com>,Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2008-10-02 21:07:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
* Alvaro Herrera <alvherre(at)commandprompt(dot)com> [081002 16:18]:
> > And, this still seems to have an issue with WAL, unless Simon's
> > original idea somehow included recording hint bit settings/dirtying
> > the page in WAL.
> I have to admit I don't remember exactly how it worked :-)  I think the
> idea was avoiding setting the page dirty until a certain number of hint
> bit setting operations had been done (which I think means it's not
> useful for the present purpose).

How crazy would I be to wonder about the performance impact of doing the
full_page_write xlog block backups at buffer dirtying time
(MarkBufferDirty and SetBufferCommitInfoNeedsSave), instead of at

A few thoughts, quite possible not true:

* The xlog backup block records don't need to be synced to disk at the
  time of the dirty but they can be synced along with stuff behind it,
  although it *needs* to be synced by the time the buffer write() comes
  long, otherwise we haven't fixed our torn page probem, so practically,
  we may need to sync it for guarentees
* OLAP workloads that handle bulk insert/update/delete are probably
  running with full_page_writes off, so don't pay the penalty of extra
  xlog writing on all the hint-bits being set
* OLTP workloads with full_page_writes on would have some extra
  full_page_writes, but I have a feeling that most dirtied buffers in
  OLTP systems are going to get changed by more than just hint-bits soon
  eonugh anyways, so it's not a huge net increase
* Slow systems that aren't high-velocity can probably spare a bit more
  Xlog bandwith anyways...

But my experience is limitted to my small-scale databases...

Aidan Van Dyk                                             Create like a god,
aidan(at)highrise(dot)ca                                       command like a king,                                   work like a slave.

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-10-02 21:19:55
Subject: Re: Block-level CRC checks
Previous:From: Ron MayerDate: 2008-10-02 20:30:21
Subject: Re: Interval output bug in HAVE_INT64_TIMESTAMP

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group