On 5/24/19 11:22 AM, Andres Freund wrote:
> Hi,
>
> On 2019-05-22 13:08:41 -0700, Andres Freund wrote:
>> On 2019-05-22 16:04:34 -0400, Andrew Dunstan wrote:
>>> If I disable install, the buildfarm fails the upgrade check even when
>>> not using NO_TEMP_INSTALL.
>>>
>>>
>>> excerpts from the
Andres Freund writes:
> Andrew, after the latest set of changes, the reversed order should now
> work reliably?
Also, Thomas should be able to revert his cfbot hack ...
regards, tom lane
Hi,
On 2019-05-22 13:08:41 -0700, Andres Freund wrote:
> On 2019-05-22 16:04:34 -0400, Andrew Dunstan wrote:
> > If I disable install, the buildfarm fails the upgrade check even when
> > not using NO_TEMP_INSTALL.
> >
> >
> > excerpts from the log:
> > sh:
On 2019-05-22 16:04:34 -0400, Andrew Dunstan wrote:
>
> On 5/22/19 2:42 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2019-05-22 14:27:51 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >>> On 2019-05-22 14:06:47 -0400, Tom Lane wrote:
> Not sure about that last bit. pg_upgrade has the
On 5/22/19 2:42 PM, Andres Freund wrote:
> Hi,
>
> On 2019-05-22 14:27:51 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> On 2019-05-22 14:06:47 -0400, Tom Lane wrote:
Not sure about that last bit. pg_upgrade has the issue of possibly
wanting to deal with 2 installations, unlike
Hi,
On 2019-05-22 14:27:51 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-05-22 14:06:47 -0400, Tom Lane wrote:
> >> Not sure about that last bit. pg_upgrade has the issue of possibly
> >> wanting to deal with 2 installations, unlike the rest of the tree,
> >> so I'm not sure that
Andres Freund writes:
> On 2019-05-22 14:06:47 -0400, Tom Lane wrote:
>> Not sure about that last bit. pg_upgrade has the issue of possibly
>> wanting to deal with 2 installations, unlike the rest of the tree,
>> so I'm not sure that fixing its problem means there's something we
>> need to
Hi,
On 2019-05-22 14:06:47 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Seems what we need to fix the immediate issue is to ressurect:
>
> > # We need to make it use psql from our temporary installation,
> > # because otherwise the installcheck run below would try to
> > # use psql from
Andres Freund writes:
> Seems what we need to fix the immediate issue is to ressurect:
> # We need to make it use psql from our temporary installation,
> # because otherwise the installcheck run below would try to
> # use psql from the proper installation directory, which might
> # be outdated
Hi,
On 2019-05-22 10:58:54 -0400, Tom Lane wrote:
> Thomas Munro writes:
> > After these commits (and Tom's commit "Un-break pg_upgrade regression
> > test."), cfbot broke:
I should just have finished working two hours earlier yesterday :(.
> > sh: 1: /usr/local/pgsql/bin/psql: not found
>
>
Thomas Munro writes:
> After these commits (and Tom's commit "Un-break pg_upgrade regression
> test."), cfbot broke:
> sh: 1: /usr/local/pgsql/bin/psql: not found
I can confirm that here: check-world passes as long as I've done
"make install" beforehand ... but of course that should not be
On Wed, May 22, 2019 at 7:41 AM Andres Freund wrote:>
> On 2019-05-21 12:19:18 -0700, Andres Freund wrote:
> > Roughly like in the attached?
>
> > -check: test.sh all
> > - MAKE=$(MAKE) bindir="$(tbindir)" libdir="$(tlibdir)"
> > EXTRA_REGRESS_OPTS="$(EXTRA_REGRESS_OPTS)" $(SHELL) $<
Hi,
On 2019-05-21 12:19:18 -0700, Andres Freund wrote:
> Roughly like in the attached?
> -check: test.sh all
> - MAKE=$(MAKE) bindir="$(tbindir)" libdir="$(tlibdir)"
> EXTRA_REGRESS_OPTS="$(EXTRA_REGRESS_OPTS)" $(SHELL) $< $(DOINST)
> +check: test.sh all temp-install
> + MAKE=$(MAKE)
Hi,
On 2019-05-21 14:48:27 -0400, Andrew Dunstan wrote:
> On 5/20/19 9:58 PM, Andres Freund wrote:
> > Hi Andrew,
> >
> > On 2019-03-30 16:42:16 -0400, Andrew Dunstan wrote:
> >> On some machines (*cough* Mingw *cough*) installs are very slow. We've
> >> ameliorated this by allowing temp installs
Andrew Dunstan writes:
> On 5/20/19 9:58 PM, Andres Freund wrote:
>> I'm confused as to why this was done as a purely optional path, rather
>> than just ripping out the pg_upgrade specific install?
> By specifying NO_TEMP_INSTALL you are in effect certifying that there is
> already a suitable
On 5/20/19 9:58 PM, Andres Freund wrote:
> Hi Andrew,
>
> On 2019-03-30 16:42:16 -0400, Andrew Dunstan wrote:
>> On some machines (*cough* Mingw *cough*) installs are very slow. We've
>> ameliorated this by allowing temp installs to be reused, but the
>> pg_upgrade Makefile never got the
Hi Andrew,
On 2019-03-30 16:42:16 -0400, Andrew Dunstan wrote:
> On some machines (*cough* Mingw *cough*) installs are very slow. We've
> ameliorated this by allowing temp installs to be reused, but the
> pg_upgrade Makefile never got the message. Here's a patch that does
> that. I'd like to
Andrew Dunstan writes:
> On some machines (*cough* Mingw *cough*) installs are very slow. We've
> ameliorated this by allowing temp installs to be reused, but the
> pg_upgrade Makefile never got the message. Here's a patch that does
> that. I'd like to backpatch it, at least to 9.5 where we
On Saturday, March 30, 2019 9:42 PM, Andrew Dunstan
wrote:
> On some machines (cough Mingw cough) installs are very slow. We've
> ameliorated this by allowing temp installs to be reused, but the
> pg_upgrade Makefile never got the message. Here's a patch that does
> that. I'd like to backpatch
On some machines (*cough* Mingw *cough*) installs are very slow. We've
ameliorated this by allowing temp installs to be reused, but the
pg_upgrade Makefile never got the message. Here's a patch that does
that. I'd like to backpatch it, at least to 9.5 where we switched the
pg_upgrade location.
20 matches
Mail list logo
