Re: [HACKERS] Re: pg_dump possible fix, need testers.

Earlier I wrote:
> (New also, though probably unrelated: the sanity check fails with number of
> index tuples exactly half number in heap - not equal)

TL> I think that you may have some subtle platform-specific problems in the
TL> backend.

On Mon, Jan 24, 2000, Tom Lane wrote:
TL> Hmm. Why don't you try running the parallel regression test, to see
TL> if that blows up too?

Rerunning the ordinary regression "runtest", the sanity_check passes. The
difference being that this time I wasn't running a select at the same time.
The parallel test "runcheck" fails on different parts at different times eg:

test select_into ... FAILED
because
! psql: connection to database "regression" failed - Backend startup failed

(BTW in resultmap, I need the .*-.*-netbsd rather than just netbsd, I think
it's because config.guess returns i386-unknown-netbsd1.4P, and just netbsd
would imply the string starts with netbsd)

3 times in a row now, gmake runtest on its own is fine, gmake runtest with a
concurrent join select makes sanity_check fail with

+ NOTICE: RegisterSharedInvalid: SI buffer overflow
+ NOTICE: InvalidateSharedInvalid: cache state reset
+ NOTICE: Index onek_stringu1: NUMBER OF INDEX' TUPLES (1000) IS NOT THE SAME AS HEAP' (2000).
+ Recreate the index.
+ NOTICE: Index onek_hundred: NUMBER OF INDEX' TUPLES (1000) IS NOT THE SAME AS
HEAP' (2000).
+ Recreate the index.

and the join will still get itself confused

select * from crsids,"tblPerson" where
newnham-> crsids.crsid != "tblPerson"."CRSID";
Backend sent B message without prior T
D21Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.
>> \.
Unknown protocol character 'M' read from backend. (The protocol character
is the first character the backend sends in response to a query it
receives).
PQendcopy: resetting connection
Asynchronous NOTIFY 'ndropoulou' from backend with pid '1818589281'
received.
Asynchronous NOTIFY 'ndropoulou' from backend with pid '1818589281'
received.

Then plenty of

pq_flush: send() failed: Broken pipe
FATAL: pq_endmessage failed: errno=32

keep on happening even though the connection is apparently dropped and psql
exited. Running a regression test during this fails sanity_check. Restart
postmaster, and the sanity_check passes. Run the join, and all breaks.

Ah - some joins work. The above join works if I replace * by "Surname". It
should return 750440 rows. It seems to just be a matter of quantity of data
going down the connection. A * row contains 428 varchars worth and about 10
numbers. Just in case it's just me, I'll build a new kernel (when in
kern_proc doubt..)

Cheers,

Patrick