Andres Freund <andres(at)2ndquadrant(dot)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
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
In response to
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2013-01-15 17:07:02|
|Subject: Re: Curious buildfarm failures|
|Previous:||From: Tom Lane||Date: 2013-01-15 16:36:50|
|Subject: Re: logical changeset generation v4|