On Thu, Apr 2, 2015 at 3:07 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> 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?
That's exactly why I think it needs to call
WaitForParallelWorkersToFinish() - because it will do just that. We
only need to invent a way of telling the worker to stop the scan and
shut down cleanly.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company