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

Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and

From: Greg Stark <gsstark(at)mit(dot)edu>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
Cc: <pgman(at)candle(dot)pha(dot)pa(dot)us>, <kleptog(at)svana(dot)org>, <simon(at)2ndquadrant(dot)com>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <gsstark(at)mit(dot)edu>, <pg(at)rbt(dot)ca>, <zhouqq(at)cs(dot)toronto(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
Date: 2005-12-29 17:20:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:

> Bruce Momjian said:
> > DROP would drop the table on a restart
> > after a non-clean shutdown.  It would do _no_ logging on the table and
> > allow concurrent access, plus index access.  DELETE is the same as
> > DROP, but it just truncates the table (perhaps TRUNCATE is a better
> > word).
> >
> > EXCLUSIVE would allow only a single session to modify the table, and
> > would do all changes by appending to the table, similar to COPY LOCK.
> > EXCLUSIVE would also not allow indexes because those can not be
> > isolated like appending to the heap.  EXCLUSIVE would write all dirty
> > shared buffers for the table and fsync them before committing.  SHARE
> > is the functionality we have now, with full logging.
> I an horribly scared that this will be used as a "performance boost" for
> normal use. I would at least like to see some restrictions that make it
> harder to mis-use. Perhaps restrict to superuser?

Well that's its whole purpose. At least you can hardly argue that you didn't
realize the consequences of "DELETE ROWS ON RECOVERY"... :)

Some thoughts:

a) I'm not sure I understand the purpose of EXCLUSIVE. When would I ever want to
   use it instead of DELETE ROWS?

b) It seems like the other feature people were talking about of not logging
   for a table created within the same transaction should be handled by
   having this flag implicitly set for any such newly created table.
   Ie, the test for whether to log would look like:

   if (!table->logged && table->xid != myxid) ...

c) Every option in ALTER TABLE should be in CREATE TABLE as well.

d) Yes as someone else mentioned, this should only be allowable on a table
   with no foreign keys referencing it. 


In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2005-12-29 17:21:47
Subject: Re: localization problem (and solution)
Previous:From: Bruce MomjianDate: 2005-12-29 17:15:23
Subject: Re: to_char and i18n

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