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? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
