Skip site navigation (1) Skip section navigation (2)

Re: Async Commit, v21 (now: v22)

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>,"Florian Weimer" <fweimer(at)bfk(dot)de>,"Peter Eisentraut" <peter_e(at)gmx(dot)net>,"Gregory Stark" <stark(at)enterprisedb(dot)com>,"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>,"Bruce Momjian" <bruce(at)momjian(dot)us>,<pgsql-patches(at)postgresql(dot)org>
Subject: Re: Async Commit, v21 (now: v22)
Date: 2007-07-24 21:24:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
On Tue, 2007-07-24 at 16:25 -0400, Tom Lane wrote:
> "Jim C. Nasby" <decibel(at)decibel(dot)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

In response to


pgsql-patches by date

Next:From: Andrei KovalevskiDate: 2007-07-24 21:33:32
Subject: Re: msvc and vista fun
Previous:From: Tom LaneDate: 2007-07-24 20:25:07
Subject: Re: Async Commit, v21 (now: v22)

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group