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: 44A2C02B.8050907@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

>Buildfarm member platypus is showing a regression failure that I'm
>surprised we have not seen before:
>
>http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=2006-06-28%2014:05:01
>
>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
>situations.
>
>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.
>
>Thoughts?
>
>
>
>

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.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

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