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

Re: Instability in TRUNCATE regression test

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Instability in TRUNCATE regression test
Date: 2006-06-28 17:56:09
Message-ID: 20060628175609.GC30996@surnet.cl (view raw or flat)
Thread:
Lists: pgsql-hackers
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > > Tom Lane wrote:
> > >> 1. Find a way to make the processing order consistent (eg by driving it
> > >> off OID ordering).  Doesn't seem easy, but maybe I'm missing an idea.
> > 
> > > Hmm, what about
> > 
> > > 1. get the complete list of tables to truncate, AccessShareLock'ed, get
> > > their names
> > > 2. release locks
> > > 3. sort the list lexicographically (or by Oid, whatever)
> > > 4. acquire the stronger locks, in list order, taking care of not
> > > aborting if a table is no longer there
> > > 5. truncate
> > 
> > Releasing locks is no good ... what if someone adds/drops FK constraints
> > while you've not got any lock?
> 
> Recheck after acquiring the stronger locks, unlock and drop from list.

Oops, this doesn't cover the "add FK constraints" case, only drop.  I
think it would work to keep the locks on the tables initially mentioned
in the command (i.e. those not followed by CASCADE).  Hmm, but it fails
if it cascades more than once, so scratch that.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-06-28 17:58:13
Subject: Re: Instability in TRUNCATE regression test
Previous:From: Alvaro HerreraDate: 2006-06-28 17:53:16
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as

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