Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

Поиск
Список
Период
Сортировка
От Jonathan S. Katz
Тема Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
Дата
Msg-id DF42863C-BB66-48C6-BE68-CE6C928F23F3@excoventures.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> On May 10, 2018, at 12:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Andres Freund <andres@anarazel.de> writes:
>> On 2018-05-10 12:18:19 -0400, Tom Lane wrote:
>>> Next question is what to do with this.  Do we want to sit on it till
>>> v12, or sneak it in now?
>
>> Is there a decent argument for sneaking it in? I don't really have an
>> opinion. I don't think it'd really be arguable that this'll make testing
>> meaningfully faster. OTOH, it's fresh in your mind (which can be said
>> about a lot of patches obviously).
>
> Yeah, I had hoped that this might make a noticeable difference on slower
> buildfarm animals, but some testing shows that it's more likely to be
> barely above the noise floor.
>
> OTOH, in view of Josh's old gripe, maybe it could be argued to be a bug
> fix, at least on platforms where it does anything.

Read back to get some history/context on this, and from my vantage
point it sounds like this is fixing a bug (i.e. incorrect behavior). It also sounds
like based on the changes the earliest we’d be able to commit is is 11 and
not any further because people could be expecting the incorrect behavior to
happen, and thus we may break existing systems.

Jonathan

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)