Re: Async Commit, v21 (now: v22) - Mailing list pgsql-patches

From Simon Riggs
Subject Re: Async Commit, v21 (now: v22)
Date
Msg-id 1185312285.4299.15.camel@ebony.site
Whole thread Raw
In response to Re: Async Commit, v21 (now: v22)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Async Commit, v21 (now: v22)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
On Tue, 2007-07-24 at 16:25 -0400, Tom Lane wrote:
> "Jim C. Nasby" <decibel@decibel.org> writes:
> > On Tue, Jul 24, 2007 at 02:08:00PM -0400, Alvaro Herrera wrote:
> >> Is it true that a transaction is turned into sync commit as soon as it
> >> writes on a system catalog?  Is it desirable to make it so?
>
> > If we don't do that then regular users have the ability to put the
> > catalog (and by extension everything else) at risk...
>
> How do you arrive at that conclusion?  The point of the async commit
> patch is that transactions might be lost, as in not really committed,
> but there can be no database corruption.  Otherwise we'd never consider
> making it a userset config setting.

There isn't an explicit test for writing to catalog tables; as Tom says
this is as safe as any other data.

There is an explicit test for whether the transaction has modified
files; if so the commit is always synchronous, even if explicitly
requested otherwise. Also, utility commands never perform async commits,
so overall there aren't that many of the commonly used DDL commands that
could be performed and still have it be an async commit.

--
  Simon Riggs
  EnterpriseDB  http://www.enterprisedb.com


pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Async Commit, v21 (now: v22)
Next
From: Gregory Stark
Date:
Subject: Re: Async Commit, v21 (now: v22)