| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: WIP checksums patch |
| Date: | 2012-11-14 22:28:09 |
| Message-ID: | CAHyXU0yRFE7hR4jbV+s3Z0knpf3AZNCnmGMKACxs_J1BBnUQqw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Oct 9, 2012 at 1:51 AM, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
> On Monday, October 01, 2012 11:11 PM Jeff Davis wrote:
>> On Mon, 2012-10-01 at 18:14 +0100, Simon Riggs wrote:
>> > You are missing large parts of the previous thread, giving various
>> > opinions on what the UI should look like for enabling checksums.
>>
>> I read through all of the discussion that I could find. There was quite
>> a lot, so perhaps I have forgotten pieces of it.
>>
>> But that one section in the docs does look out of date and/or confusing
>> to me.
>>
>> I remember there was discussion about a way to ensure that checksums are
>> set cluster-wide with some kind of special command (perhaps related to
>> VACUUM) and a magic file to let recovery know whether checksums are set
>> everywhere or not. That doesn't necessarily conflict with the GUC though
>> (the GUC could be a way to write checksums lazily, while this new
>> command could be a way to write checksums eagerly).
>>
>> If some consensus was reached on the exact user interface, can you
>> please send me a link?
>
> AFAICT complete consensus has not been reached but one of the discussions can be found on below link:
> http://archives.postgresql.org/pgsql-hackers/2012-03/msg00279.php
> Here Robert has given suggestions and then further there is more discussion based on that points.
>
> According to me, the main points where more work for this patch is required as per previous discussions is as follows:
>
> 1. Performance impact of WAL log for hint-bits needs to be verified for scenario's other than pg_bench (Such as bulk data load (which I
> feel there is some way to optimize, but I don't know if that’s part of this patch)).
Atri has a patch posted which (if it passes muster) would eliminate
the i/o impact of WAL logging hint bits following a bulk load or any
scenario where many pages worth of tuples were sequentially written
out with the same XID. Atri's patch was written with the checksum
patch in mind.
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2012-11-14 22:32:12 | pgsql: In pg_upgrade, copy fsm, vm, and extent files by checking for fi |
| Previous Message | Xi Wang | 2012-11-14 22:08:52 | Re: [PATCH] Fix INT_MIN % -1 overflow in int8mod(). |