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

Re: Instability in TRUNCATE regression test

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Instability in TRUNCATE regression test
Date: 2006-06-28 17:45:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:

>Buildfarm member platypus is showing a regression failure that I'm
>surprised we have not seen before:
>Basically what this is showing is that when there is more than one
>referencing table, the order in which things get done is dependent
>on chance locations of system catalog entries.  That results in
>cosmetic differences in which of multiple violations gets reported,
>or in the order of "truncate cascades to" notices.
>Given our push to have the buildfarm "all green all the time",
>I don't think I want to just live with occasional failures.
>Seems like the alternatives are
>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.
>2. Install multiple expected files for the truncate test.
>3. Dumb down the test cases so that they don't test multiple-cascade
>Don't much care for any of these :-(.
>Also, it seems possible that not-so-cosmetic problems could occur, for
>instance deadlock between two backends trying to truncate the same
>tables in different orders.  That suggests that answer #1 would be the
>best way to fix it, but that would mean ordering the tables consistently
>before we even get any locks on them, which seems hard.

If this were a significant risk wouldn't we have seen many such failures 
before now? I guess we don't expect to see concurrent truncates being 
run. Probably worth protecting against, but also probably something of a 
corner case.

In the absence of a fix I'd go for the extra regression result file.



In response to


pgsql-hackers by date

Next:From: markDate: 2006-06-28 17:47:33
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as
Previous:From: Jim C. NasbyDate: 2006-06-28 17:38:50
Subject: Re: Fixed length datatypes. WAS [GENERAL] UUID's as

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