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 <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
