On Fri, Feb 2, 2018 at 6:11 AM, Robert Haas wrote:
>> Fair enough, you can proceed with the patch.
>
> Committed. Now, on to the main event!
Thank you both.
--
Peter Geoghegan
On Thu, Feb 1, 2018 at 9:48 PM, Amit Kapila wrote:
> On Thu, Feb 1, 2018 at 9:09 PM, Robert Haas wrote:
>> On Wed, Jan 31, 2018 at 10:08 PM, Amit Kapila
>> wrote:
>>> I think suggesting to use this API to wait "for a specific worker"
>>> doesn't seem like a good idea as it doesn't have any such
On Thu, Feb 1, 2018 at 9:09 PM, Robert Haas wrote:
> On Wed, Jan 31, 2018 at 10:08 PM, Amit Kapila wrote:
>> I think suggesting to use this API to wait "for a specific worker"
>> doesn't seem like a good idea as it doesn't have any such provision.
>
> I see your point, but in the absence of a mor
On Wed, Jan 31, 2018 at 10:08 PM, Amit Kapila wrote:
> I think suggesting to use this API to wait "for a specific worker"
> doesn't seem like a good idea as it doesn't have any such provision.
I see your point, but in the absence of a more specific API it could
be used that way, and it wouldn't b
On Wed, Jan 31, 2018 at 9:53 PM, Robert Haas wrote:
> On Wed, Jan 31, 2018 at 3:57 AM, Amit Kapila wrote:
>>> * There might be some opportunity to share some of the new code with
>>> the code recently committed to WaitForParallelWorkersToFinish(). For
>>> one thing, the logic in this block could
On Wed, Jan 31, 2018 at 3:57 AM, Amit Kapila wrote:
>> * There might be some opportunity to share some of the new code with
>> the code recently committed to WaitForParallelWorkersToFinish(). For
>> one thing, the logic in this block could be refactored into a
>> dedicated function that is called
On Mon, Jan 29, 2018 at 4:01 AM, Peter Geoghegan wrote:
> On Sat, Jan 27, 2018 at 12:14 AM, Amit Kapila wrote:
>
> I also found that all of these errors were propagated. The patch helps
> parallel CREATE INDEX as expected/designed.
>
Great!
> Some small things that I noticed about the patch:
>
On Wed, Jan 31, 2018 at 8:46 AM, Robert Haas wrote:
> On Tue, Jan 30, 2018 at 10:10 PM, Amit Kapila wrote:
>> I am not getting what exactly you are suggesting here. The wait loop
>> is intended for the case when some workers are not started. We want
>> to wait for sometime before checking again
On Tue, Jan 30, 2018 at 10:10 PM, Amit Kapila wrote:
>> known_started_workers looks a lot like any_message_received. Perhaps
>> any_message_received should be renamed to known_started_workers and
>> reused here.
>
> Sure, that sounds good to me. Do you prefer a separate patch for
> renaming any_
On Mon, Jan 29, 2018 at 8:25 PM, Robert Haas wrote:
> On Sat, Jan 27, 2018 at 3:14 AM, Amit Kapila wrote:
>> During the recent development of parallel operation (parallel create
>> index)[1], a need has been arised for $SUBJECT. The idea is to allow
>> leader backend to rely on number of workers
On Sat, Jan 27, 2018 at 3:14 AM, Amit Kapila wrote:
> During the recent development of parallel operation (parallel create
> index)[1], a need has been arised for $SUBJECT. The idea is to allow
> leader backend to rely on number of workers that are successfully
> started. This API allows leader
On Sat, Jan 27, 2018 at 12:14 AM, Amit Kapila wrote:
> During the recent development of parallel operation (parallel create
> index)[1], a need has been arised for $SUBJECT. The idea is to allow
> leader backend to rely on number of workers that are successfully
> started. This API allows leader
During the recent development of parallel operation (parallel create
index)[1], a need has been arised for $SUBJECT. The idea is to allow
leader backend to rely on number of workers that are successfully
started. This API allows leader to wait for all the workers to start
or fail even if one of t
13 matches
Mail list logo
