From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] make check error on -HEAD |
Date: | 2004-11-01 19:06:55 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE476074@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
>>>I have just seen this failure on Windows - it appears to
>have nothing to
>>>do there with finding an out of date libpq.
>>
>>Actually, *any* failure in pg_regress's first attempt to invoke psql
>>yields this message. I tweaked the script yesterday to not suppress
>>stderr; do you have that update yet?
>
>Yes, but on Windows it doesn't give anything on stderr, it gives me a
>nasty popup with no useful info I can see, and wants to send
>info off to
>microsoft.
That's just the lovely way windows handles a "segfault". Gotta be really
interesting for MS to catch all those dumps...
Anyway. Oops. Seems I ran my regression tests with the old psql, and
just managed to update the backend, when I tested that patch. Turns out
there are codepaths where we'd access the Critical Section before it was
initialized. Attached patch breaks the initializeation off to a separate
part and adds that one to a much earlier position in the program.
I've verified with Andrew that this fixes his problem.
//Magnus
Attachment | Content-Type | Size |
---|---|---|
psql_win32lock.patch | application/octet-stream | 1.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-11-01 19:21:40 | Re: [HACKERS] make check error on -HEAD |
Previous Message | a_ogawa | 2004-11-01 14:25:18 | Re: Cache last known per-tuple offsets to speed long tuple |