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

Re: NOLOGGING option, or ?

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Greg Stark <gsstark(at)mit(dot)edu>, Neil Conway <neilc(at)samurai(dot)com>,Alvaro Herrera <alvherre(at)surnet(dot)cl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: NOLOGGING option, or ?
Date: 2005-06-01 22:47:17
Message-ID: 1117666037.3844.1127.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, 2005-06-01 at 18:32 -0400, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > One idea would be to look at the table file size first.  If it has zero
> > blocks, lock the table and if it still has zero blocks, do the no-WAL
> > copy.
> I think that's a bad idea.  It would make the behavior unpredictable
> --- sometimes a COPY will take an exclusive lock, and other times not;
> and the reason why is at a lower semantic level than the user is
> supposed to know about.
> Before you say "this is not important", consider the nontrivial risk
> that the stronger lock will cause a deadlock failure.  I don't think
> that it's acceptable for lock strength to be unpredictable.

While I agree with Bruce's sentiment, the locking is an issue with

It is particularly important to be able to plan the concurrency within
an application. That is why DB2's interesting ability to perform lock
upgrades in a relatively unpredictable manner is not good.

For CREATE TABLE AS SELECT, I think we could do this Bruce's way and
win, since we would take the same grade of lock in both cases.

Best Regards, Simon Riggs

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2005-06-01 23:00:34
Subject: Re: NOLOGGING option, or ?
Previous:From: Simon RiggsDate: 2005-06-01 22:39:59
Subject: Re: NOLOGGING option, or ?

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