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

Re: Block-level CRC checks

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql(at)mohawksoft(dot)com,"Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>,Hannu Krosing <hannu(at)2ndquadrant(dot)com>,Decibel! <decibel(at)decibel(dot)org>,Alvaro Herrera <alvherre(at)commandprompt(dot)com>,Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2008-10-02 00:17:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [081001 19:42]:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> > a) You wouldn't have to keep the lock while doing the I/O.
> Hoo, yeah, so the period of holding the share-lock could well be
> *shorter* than it is now.  Most especially so if the write() blocks
> instead of just transferring the data to kernel space and returning.
> I wonder whether that could mean that it's a win to double-buffer
> even if we aren't computing a checksum?  Nah, probably not.

That all depends on what you think is longer: copy 8K & release, or
syscall(which obviously does a copy)+return & release... And whether you
want to shorten the lock hold time (but it's only shared), or the time
until write is done (isn't the goal to have writes being done in the
background during checkpoint so write latency isn't a problem)...  This
might be an interesting experiment for someone to do with a very high
concurrency, high-write load...


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: Alvaro HerreraDate: 2008-10-02 00:34:42
Subject: Re: Transactions within a function body
Previous:From: Tom LaneDate: 2008-10-01 23:41:24
Subject: Re: Block-level CRC checks

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