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  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: logical changeset generation v4
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Curious buildfarm failures