Re: Curious buildfarm failures
От | Tom Lane |
---|---|
Тема | Re: Curious buildfarm failures |
Дата | |
Msg-id | 27601.1358269027@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Curious buildfarm failures (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Curious buildfarm failures
|
Список | 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 по дате отправления: