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

Re: NOLOGGING option, or ?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Neil Conway <neilc(at)samurai(dot)com>,Alvaro Herrera <alvherre(at)surnet(dot)cl>,Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: NOLOGGING option, or ?
Date: 2005-06-01 23:02:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

Yea, but you are only doing the lock if the table is zero pages. 
Doesn't that help?  Maybe not.

I do like the LOCK keyword if we have to use one to enable this
functionality, but I am suspecting people will want this functionality
in pg_dump output.  How do we do that?  Just make it the default for
pg_dump output?

  Bruce Momjian                        |
  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

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2005-06-01 23:06:07
Subject: Re: NOLOGGING option, or ?
Previous:From: Bruce MomjianDate: 2005-06-01 23:00:34
Subject: Re: NOLOGGING option, or ?

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