Re: Curious buildfarm failures - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Curious buildfarm failures
Date
Msg-id 27601.1358269027@sss.pgh.pa.us
Whole thread Raw
In response to Re: Curious buildfarm failures  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Curious buildfarm failures
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> Interestingly the compiler couldn't deduce that
> e.g. DateTimeParseError() didn't return with the old ereport definition
> but it can with the new one which seems strange.

Oooh, I hadn't noticed that.  I guess that must indicate that this
version of icc can deduce unreachability from
if (true)    abort();

but not from
(true) ? abort() : (void) 0;

which is a bit odd but not incredible.  (I had actually wondered while
working on the patch if this wording might be better for some compilers;
seems that's the case.)

What that means is that this compiler was not previously aware that
either ereport(ERROR) or elog(ERROR) doesn't return, but it now knows
that for both.  So that greatly expands the scope of places where
behavior might have changed.  Doesn't simplify our task :-(

>> I'm betting the answer is "none", and that what's happening is some sort
>> of timing problem (ie, the DROP TABLESPACE somehow isn't waiting for the
>> checkpointer process to clean out all the just-dropped files).

> It seems strange tho that it started failing exactly with that commit
> and all runs failed exactly the same way since.

Well, it could be quite reproducible, if for example what's happening is
that the DROP is failing to wait for the checkpointer at all.

Is there a way to enable log_checkpoints during a buildfarm run?
It'd be good to get timestamps added to the postmaster log entries, too.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: logical changeset generation v4
Next
From: Andrew Dunstan
Date:
Subject: Re: Curious buildfarm failures