Re: Parallel Seq Scan
| От | Amit Kapila |
|---|---|
| Тема | Re: Parallel Seq Scan |
| Дата | |
| Msg-id | CAA4eK1K+N1wva2UdvfSXaLqRBNMUrMUEsMNW2A7cwo5dyETg3Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Parallel Seq Scan (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: Parallel Seq Scan
|
| Список | pgsql-hackers |
On Wed, Apr 1, 2015 at 6:11 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, Apr 1, 2015 at 7:30 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >> Also, the new code to propagate
> >> XactLastRecEnd won't work right, either.
> >
> > As we are generating FATAL error on termination of worker
> > (bgworker_die()), so won't it be handled in AbortTransaction path
> > by below code in parallel-mode patch?
>
> That will asynchronously flush the WAL, but if the master goes on to
> commit, we've wait synchronously for WAL flush, and possibly sync rep.
>
Okay, so you mean if master backend later commits, then there is
>
> On Wed, Apr 1, 2015 at 7:30 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >> Also, the new code to propagate
> >> XactLastRecEnd won't work right, either.
> >
> > As we are generating FATAL error on termination of worker
> > (bgworker_die()), so won't it be handled in AbortTransaction path
> > by below code in parallel-mode patch?
>
> That will asynchronously flush the WAL, but if the master goes on to
> commit, we've wait synchronously for WAL flush, and possibly sync rep.
>
Okay, so you mean if master backend later commits, then there is
a chance of loss of WAL data written by worker.
Can't we report the location to master as the patch does in case of
Commit in worker?
В списке pgsql-hackers по дате отправления: