Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Parallel Seq Scan
Date
Msg-id CAA4eK1K+N1wva2UdvfSXaLqRBNMUrMUEsMNW2A7cwo5dyETg3Q@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Parallel Seq Scan
List 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
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?


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Logical decoding (contrib/test_decoding) walsender broken in 9.5 master?
Next
From: Pavel Stehule
Date:
Subject: Re: PL/pgSQL, RAISE and error context