From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: COMMIT NOWAIT Performance Option |
Date: | 2007-02-27 20:56:12 |
Message-ID: | 19370.1172609772@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> Josh Berkus wrote:
>> It seriously narrows down the problem space to know that PostgreSQL does *not*
>> allow data loss if it's physically possible to prevent it.
> But we do don't we? fsync = off, full_page_writes = off?
One of the things that's really attractive about the proposed mode is
that it does *not* create a risk of data corruption (assuming that
Simon's analyzed it correctly --- I think the clog code in particular
needs a look). What you risk is that when the database comes back up,
its state may reflect an instant up to X seconds before the time of the
crash, rather than exactly the crash time. It seems to me that that's
way better than fsync = off, which allows unlimited corruption.
I agree that we ought to look at some performance numbers before
accepting the patch, but I think Josh's argument that this opens us
up to major corruption problems is probably wrong. The question is
whether your application can tolerate loss of "very recent" transactions,
and I think there are plenty where it can.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jonah H. Harris | 2007-02-27 21:01:46 | Re: COMMIT NOWAIT Performance Option |
Previous Message | Andrew Dunstan | 2007-02-27 20:50:16 | Re: conversion efforts (Re: SCMS question) |