Re: COMMIT NOWAIT Performance Option

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

In response to

Responses

Browse pgsql-hackers by date

  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)