further (anecdotal) data point: I have usually seen this after doing a
number of builds. Rebooting seems to cure the problem (and that's
happened today agin - I have just seen 2 builds work). Maybe some sort
of strange shmem corruption?
cheers
andrew
Tom Lane wrote:
>Andrew Dunstan <andrew@dunslane.net> writes:
>
>
>>I never got a reply to this, but I am still seeing it from time to time
>>- twice today in fact. Any suggestions?
>>
>>
>
>I've been puzzled by that too. It seems to indicate that the syscache
>inval message that the COMMIT should send is either not getting sent at
>all, or is being processed too late. Neither of these ideas seems very
>promising, especially considering that we're looking at a single backend
>as both source and recipient of the message --- a race condition doesn't
>seem credible. And there's nothing very platform-specific in that code
>either. (I tried for awhile to explain it as some kind of deficiency
>in the signal emulation we use on Windows, but there's no signals used
>for normal sinval processing, so that doesn't seem to hold water.)
>
>Are we sure that it only happens on Windows? Anyone else seen a similar
>failure in the prepared_xacts test?
>
>
>
>>>*** ./expected/prepared_xacts.out Thu Jul 7 09:55:18 2005
>>>--- ./results/prepared_xacts.out Thu Jul 7 10:20:37 2005
>>>***************
>>>*** 179,189 ****
>>>-- Commit table creation
>>>COMMIT PREPARED 'regress-one';
>>>\d pxtest2
>>>! Table "public.pxtest2"
>>>! Column | Type | Modifiers ! --------+---------+-----------
>>>! a | integer | ! SELECT * FROM pxtest2;
>>>a ---
>>>--- 179,185 ----
>>>-- Commit table creation
>>>COMMIT PREPARED 'regress-one';
>>>\d pxtest2
>>>! ERROR: cache lookup failed for relation 27240
>>>SELECT * FROM pxtest2;
>>>a ---
>>>
>>>
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: don't forget to increase your free space map settings
>
>
>
