On Wed, 18 Dec 2019 at 07:23, Michael Paquier wrote:
>
> On Tue, Dec 17, 2019 at 11:40:17PM +0530, Mahendra Singh wrote:
> > I found some inconsistency in alphabetical order in
> > src/backend/tsearch/Makefile, src/backend/utils/Makefile and
> > src/pl/plpython/Makefile files. Attached patch is
On Tue, Dec 17, 2019 at 11:40:17PM +0530, Mahendra Singh wrote:
> I found some inconsistency in alphabetical order in
> src/backend/tsearch/Makefile, src/backend/utils/Makefile and
> src/pl/plpython/Makefile files. Attached patch is fixing those order
> related inconsistency.
Thanks, committed.
On Fri, 8 Nov 2019 at 14:38, Michael Paquier wrote:
>
> On Thu, Nov 07, 2019 at 12:02:04PM -0500, Tom Lane wrote:
> > I don't think it'd be a great idea to change parallel_schedule like
> > that. Independently adding test scripts to the same parallel batch
> > probably won't end well: you might
On Thu, Nov 07, 2019 at 12:02:04PM -0500, Tom Lane wrote:
> I don't think it'd be a great idea to change parallel_schedule like
> that. Independently adding test scripts to the same parallel batch
> probably won't end well: you might end up over the concurrency limit,
> or the scripts might
Hi,
On 2019-11-07 11:24:37 +0900, Michael Paquier wrote:
> On Tue, Nov 05, 2019 at 02:47:55PM -0800, Andres Freund wrote:
> > Pushed a patch going with the former. Let's see what the buildfarm
> > says...
>
> Thanks Andres. On a rather related note, would it make sense to do
> the same for
Michael Paquier writes:
> On Tue, Nov 05, 2019 at 02:47:55PM -0800, Andres Freund wrote:
>> Pushed a patch going with the former. Let's see what the buildfarm
>> says...
> Thanks Andres. On a rather related note, would it make sense to do
> the same for regression and isolation tests in our
On Tue, Nov 05, 2019 at 02:47:55PM -0800, Andres Freund wrote:
> Pushed a patch going with the former. Let's see what the buildfarm
> says...
Thanks Andres. On a rather related note, would it make sense to do
the same for regression and isolation tests in our in-core modules?
--
Michael
Hi,
On 2019-10-29 23:32:09 -0700, Andres Freund wrote:
> On 2019-10-29 16:31:11 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > one of the most frequent conflicts I see is that two patches add files
> > > to OBJS (or one of its other spellings), and there are conflicts because
> > >
On 10/29/19 11:32 PM, Andres Freund wrote:
Hi,
On 2019-10-29 16:31:11 -0400, Tom Lane wrote:
Andres Freund writes:
one of the most frequent conflicts I see is that two patches add files
to OBJS (or one of its other spellings), and there are conflicts because
another file has been added.
On Tue, Oct 29, 2019 at 11:32:09PM -0700, Andres Freund wrote:
> Cool. Any opinion on whether to got for
>
> OBJS = \
> dest.o \
> fastpath.o \
> ...
>
> or
>
> OBJS = dest.o \
> fastpath.o \
> ...
>
> I'm mildly inclined to go for the former.
FWIW, I am more used to the
Andres Freund writes:
> On 2019-10-29 16:31:11 -0400, Tom Lane wrote:
>> We did something similar not too long ago in configure.in (bfa6c5a0c),
>> and it seems to have helped. +1
> Cool. Any opinion on whether to got for ...
Not here.
regards, tom lane
Hi,
On 2019-10-29 16:31:11 -0400, Tom Lane wrote:
> Andres Freund writes:
> > one of the most frequent conflicts I see is that two patches add files
> > to OBJS (or one of its other spellings), and there are conflicts because
> > another file has been added.
> > ...
> > Now, obviously these
Andres Freund writes:
> one of the most frequent conflicts I see is that two patches add files
> to OBJS (or one of its other spellings), and there are conflicts because
> another file has been added.
> ...
> Now, obviously these types of conflicts are easy enough to resolve, but
> it's still
On Tue, Oct 29, 2019 at 1:09 PM Andres Freund wrote:
> Comments?
I think that this is a good idea. I see no downside.
--
Peter Geoghegan
14 matches
Mail list logo
