Re: postgres_fdw vs. force_parallel_mode on ppc

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: postgres_fdw vs. force_parallel_mode on ppc
Дата
Msg-id CA+TgmoaR=NM_pHbNkUhWXcL6jppO0-kp_ztQmq+EB-fRd4HGVQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: postgres_fdw vs. force_parallel_mode on ppc  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: postgres_fdw vs. force_parallel_mode on ppc  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Mar 4, 2016 at 11:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Mar 4, 2016 at 11:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Well, that would make the function more complicated, but maybe it's a
>>> better answer.  On the other hand, we know that the stats updates are
>>> delivered in a deterministic order, so why not simply replace the
>>> existing test in the wait function with one that looks for the truncation
>>> updates?  If we've gotten those, we must have gotten the earlier ones.
>
>> I'm not sure if that's actually true with parallel mode.  I'm pretty
>> sure the earlier workers will have terminated before the later ones
>> start, but is that enough to guarantee that the stats collector sees
>> the messages in that order?
>
> Huh?  Parallel workers are read-only; what would they be doing sending
> any of these messages?

Mumble.  I have no idea what's happening here.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: postgres_fdw vs. force_parallel_mode on ppc
Следующее
От: Anastasia Lubennikova
Дата:
Сообщение: Re: [PATCH] Supporting +-Infinity values by to_timestamp(float8)