Re: Instability in TRUNCATE regression test

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