Re: COMMIT NOWAIT Performance Option - Mailing list pgsql-hackers

From Tom Lane
Subject Re: COMMIT NOWAIT Performance Option
Date
Msg-id 19370.1172609772@sss.pgh.pa.us
Whole thread Raw
In response to Re: COMMIT NOWAIT Performance Option  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: COMMIT NOWAIT Performance Option  (Josh Berkus <josh@agliodbs.com>)
Re: COMMIT NOWAIT Performance Option  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
"Joshua D. Drake" <jd@commandprompt.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


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: conversion efforts (Re: SCMS question)
Next
From: "Jonah H. Harris"
Date:
Subject: Re: COMMIT NOWAIT Performance Option