From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Block-level CRC checks |
Date: | 2008-11-18 17:23:24 |
Message-ID: | 20081118172324.GI4141@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Aidan Van Dyk wrote:
> And I don't think anyone's going to have a good answer either way unless we get
> real numbers. But I don't know of any way to get at these numbers right now.
>
> 1) How many writes happen on buffer pages that are "hint dirty" but not "really
> dirty"?
>
> 2) How much IO would writing the WAL records "hint bits" on every page write
> take up?
I don't think it's a matter of hoy many writes or how much IO. The
question is locks. Right now we flip hint bits without taking any kind
of lock on the page. If we're going to WAL-log each hint bit change,
then we will need to lock the page to update the LSN. This will make
changing a hint bit a very expensive operation, and maybe a possible
cause for deadlocks.
What my patch did was log hint bits in bulk. The problem of that
approach was precisely that it was not locking the logged page enough
(locking before setting the "this page needs hint bits logged" bit). Of
course, the trivial solution is just to lock the page before flipping
hint bits, but I don't know (and I doubt) whether it would really work
at all.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-11-18 17:31:48 | Re: Block-level CRC checks |
Previous Message | Simon Riggs | 2008-11-18 17:15:01 | Re: Updates of SE-PostgreSQL 8.4devel patches (r1197) |