Re: [HACKERS] Instability in TRUNCATE regression test

2006-06-28 Thread Alvaro Herrera
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

Re: [HACKERS] Instability in TRUNCATE regression test

2006-06-28 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] 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

Re: [HACKERS] Instability in TRUNCATE regression test

2006-06-28 Thread Jim C. Nasby
On Wed, Jun 28, 2006 at 01:13:42PM -0400, Tom Lane wrote: One thing I was toying with was to add an index to pg_constraint on, say, (confrelid, conrelid), and to replace the existing seqscans for FK constraints with scans using this index. The second-column ordering would guarantee everybody

Re: [HACKERS] Instability in TRUNCATE regression test

2006-06-28 Thread Andrew Dunstan
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=platypusdt=2006-06-28%2014:05:01 Basically what this is showing is that when there is more than one referencing table, the

Re: [HACKERS] Instability in TRUNCATE regression test

2006-06-28 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] 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,

Re: [HACKERS] Instability in TRUNCATE regression test

2006-06-28 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: If this were a significant risk wouldn't we have seen many such failures before now? Hard to tell. It's possibly architecture-dependent, for one thing (MAXALIGN will affect space availability). Since this happened in a parallel regression run, it

Re: [HACKERS] Instability in TRUNCATE regression test

2006-06-28 Thread Alvaro Herrera
Alvaro Herrera wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] 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

Re: [HACKERS] Instability in TRUNCATE regression test

2006-06-28 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: One thing I was toying with was to add an index to pg_constraint on, say, (confrelid, conrelid), and to replace the existing seqscans for FK constraints with scans using this index. I think there is more than one place that would

Re: [HACKERS] Instability in TRUNCATE regression test

2006-06-28 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: 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=platypusdt=2006-06-28%2014:05:01 If this were a significant risk wouldn't we have

Re: [HACKERS] Instability in TRUNCATE regression test

2006-06-28 Thread Tom Lane
I wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: One thing I was toying with was to add an index to pg_constraint on, say, (confrelid, conrelid), and to replace the existing seqscans for FK constraints with scans using this index. I think there is more than one place that