| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | pgsql(at)mohawksoft(dot)com |
| Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Aidan Van Dyk" <aidan(at)highrise(dot)ca>, "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-01 23:29:21 |
| Message-ID: | 87vdwbevxq.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
pgsql(at)mohawksoft(dot)com writes:
> If you are going to double buffer, one presumes that for some non-zero
> period of time, the block must be locked during which it is copied. You
> wouldn't want it changing "mid-copy" would you? How is this any less of a
> hit than just calculating the checksum?
a) You wouldn't have to keep the lock while doing the I/O. Once the CRC+copy
is done you can release the lock secure in the knowledge that nobody is going
to modify your buffered copy before the kernel can grab its copy.
b) You don't have to worry about hint bits being modified underneath you. As
long as the CRC+copy is carefully written to copy whole atomic-sized
words/bytes and only read the original once then it won't matter if it catches
the hint bit before or after it's set. The CRC will reflect the value buffered
and eventually written.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-10-01 23:41:24 | Re: Block-level CRC checks |
| Previous Message | Matthew T. O'Connor | 2008-10-01 23:18:22 | Re: September CommitFest Closed |