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
12 matches
Mail list logo