| 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: | Whole Thread | Raw Message | 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 |