On Thu, Apr 2, 2015 at 3:07 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Wed, Apr 1, 2015 at 6:11 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Apr 1, 2015 at 7:30 AM, Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
