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

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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, simon(at)2ndquadrant(dot)com, kleptog(at)svana(dot)org, 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: 2006-01-03 22:38:25
Message-ID: 200601032238.k03McP804163@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Jim C. Nasby wrote:
> > We would be creating a new lock type for this.
> 
> Sorry if I've just missed this in the thread, but what would  the new
> lock type do? My impression is that as it stands you can either do:
> 
> BEGIN;
> ALTER TABLE EXCLUSIVE;
> ...
> ALTER TABLE SHARE; --fsync
> COMMIT;
> 
> Which would block all other access to the table as soon as the first
> ALTER TABLE happens. Or you can:
> 
> ALTER TABLE EXCLUSIVE;
> ...
> ALTER TABLE SHARE;
> 
> Which means that between the two ALTER TABLES every backend that does
> DML on that table will not have that DML logged, but because there's no
> exclusive lock that DML would be allowed to occur.

Right, the DML will be single-threaded and fsync of all dirty pages will
happen before commit of each transaction.

> BTW, there might be some usecase for the second scenario, in which case
> it would probably be better to tell the user to aquire a table-lock on
> their own rather than do it automatically as part of the update...

> > Basically meaning your idea of update while EXCLUSIVE/PRESERVE/STABLE is
> > happening is never going to be implemented because it is just too hard
> > to do, and too prone to error.
> 
> What I figured. Never hurts to ask though. :)

Actually, it does hurt because it generates discussion volume for no
purpose.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2006-01-03 22:53:53
Subject: Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
Previous:From: Larry RosenmanDate: 2006-01-03 22:33:09
Subject: Re: Why don't we allow DNS names in pg_hba.conf?

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