Re: Parallel Seq Scan
От | Robert Haas |
---|---|
Тема | Re: Parallel Seq Scan |
Дата | |
Msg-id | CA+TgmoZXNY_Oj46fOgpP0Dk+=Pvco3UXq33O0JPMM8wM=pyJXg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel Seq Scan (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: