Alexander Lakhin writes:
> 01.07.2019 13:47, Thomas Munro wrote:
>> A new CF is here and this is in "Needs Review". Would you like to
>> provide a rebased patch, or should it really be withdrawn?
> The rebased patch is attached, but I still can't find anyone interested
> in reviewing it.
> So le
Hello Thomas,
01.07.2019 13:47, Thomas Munro wrote:
>
> A new CF is here and this is in "Needs Review". Would you like to
> provide a rebased patch, or should it really be withdrawn?
The rebased patch is attached, but I still can't find anyone interested
in reviewing it.
So let's withdraw it.
Wit
On Mon, Mar 25, 2019 at 8:30 PM Alexander Lakhin wrote:
> 25.03.2019 10:25, David Steele wrote:
> > If it doesn't attract more review or a committer during this CF, I
> > think we should mark it as rejected.
> Please, delay rejecting it till the end of the commitfest, I'll try to
> find some enth
Hello David,
25.03.2019 10:25, David Steele wrote:
> Hi Alexander,
>
> On 2/18/19 8:07 AM, Michael Paquier wrote:
>> On Thu, Feb 14, 2019 at 11:40:29AM -0800, Andres Freund wrote:
>>> I'm confused. I don't see the patch as ready, given the discussion, nor
>>> does
>>> https://commitfest.postgresql
Hi Alexander,
On 2/18/19 8:07 AM, Michael Paquier wrote:
On Thu, Feb 14, 2019 at 11:40:29AM -0800, Andres Freund wrote:
I'm confused. I don't see the patch as ready, given the discussion, nor
does
https://commitfest.postgresql.org/22/1672/
contain a record of it ever being set to RFC? Did you i
On Thu, Feb 14, 2019 at 11:40:29AM -0800, Andres Freund wrote:
> I'm confused. I don't see the patch as ready, given the discussion, nor
> does
> https://commitfest.postgresql.org/22/1672/
> contain a record of it ever being set to RFC? Did you intend to reply to
> a different thread?
Indeed, the
Hi,
On 2019-02-04 11:11:03 +0900, Michael Paquier wrote:
> On Mon, Dec 03, 2018 at 11:58:13AM +0300, Alexander Lakhin wrote:
> > Rebased the patch once more after d3c09b9b.
>
> The patch is ready for committer, so it has not attracted much
> attention. Perhaps Teodor or Alexander could look at i
04.02.2019 5:09, Michael Paquier wrote:
> On Mon, Dec 03, 2018 at 11:58:13AM +0300, Alexander Lakhin wrote:
>> Rebased the patch once more after d3c09b9b.
> Moved to next CF, waiting on author as the patch conflicts with HEAD.
> --
> Michael
Hello Michael,
It's very strange, I looked at http://cfbo
On Mon, Dec 03, 2018 at 11:58:13AM +0300, Alexander Lakhin wrote:
> Rebased the patch once more after d3c09b9b.
The patch is ready for committer, so it has not attracted much
attention. Perhaps Teodor or Alexander could look at it?
I have moved the patch to next CF with the same status.
--
Micha
On Mon, Dec 03, 2018 at 11:58:13AM +0300, Alexander Lakhin wrote:
> Rebased the patch once more after d3c09b9b.
Moved to next CF, waiting on author as the patch conflicts with HEAD.
--
Michael
signature.asc
Description: PGP signature
Hello,
01.12.2018 09:12, Alexander Lakhin wrote:
> 30.11.2018 23:59, Dmitry Dolgov wrote:
>> Hi,
>>
>> I've noticed that for this patch cfbot show strange error
>>
>> USE_INSTALLED_ASSETS=1 make all
> I've fixed the patch.
Rebased the patch once more after d3c09b9b.
Best regards,
Alexander
diff
Hello,
30.11.2018 23:59, Dmitry Dolgov wrote:
>> On Sun, Nov 18, 2018 at 8:31 AM Alexander Lakhin wrote:
>>
>> I've modified the patch to use the installed version of pg_regress. It
>> simplifies a lot. The main idea of the change is to not build pg_regress.
> Hi,
>
> I've noticed that for this p
> On Sun, Nov 18, 2018 at 8:31 AM Alexander Lakhin wrote:
>
> I've modified the patch to use the installed version of pg_regress. It
> simplifies a lot. The main idea of the change is to not build pg_regress.
Hi,
I've noticed that for this patch cfbot show strange error
USE_INSTALLED_ASSETS=1 m
Alexander Lakhin writes:
> 12.09.2018 10:20, Michael Paquier wrote:
>> On Mon, May 07, 2018 at 01:07:15PM -0400, Tom Lane wrote:
>>> Nah, I disagree with this. To me, the purpose of "make installcheck"
>>> is to verify the correctness of an installation, which I take to include
>>> the client pro
Hello Michael,
12.09.2018 10:20, Michael Paquier wrote:
> On Mon, May 07, 2018 at 01:07:15PM -0400, Tom Lane wrote:
>> Robert Haas writes:
>>> After thinking about this some more, I think the question here is
>>> definitional. A first attempt at defining 'make installcheck' is to
>>> say that it
On Mon, May 07, 2018 at 01:07:15PM -0400, Tom Lane wrote:
> Robert Haas writes:
>> After thinking about this some more, I think the question here is
>> definitional. A first attempt at defining 'make installcheck' is to
>> say that it runs the tests from the build tree against the running
>> serv
Alexander Lakhin writes:
> 31.07.2018 02:42, Tom Lane wrote:
>> Alexander's USE_INSTALLED_ASSETS patch attempted to fix that, and I now
>> see the point of it, but it still seems pretty hacky and invasive (why
>> should an ecpg-only problem be touching stuff outside ecpg)? Also,
>> unless I'm sti
31.07.2018 02:42, Tom Lane wrote:
> I wrote:
>> The original complaint about ecpg remains; I'm not terribly excited
>> about messing with that.
> Well, I got curious as to why we were seeing such a weird error,
> and eventually traced it to this stuff in ecpg/test/Makefile.regress:
>
> # Standard w
Hello Tom,
31.07.2018 01:16, Tom Lane wrote:
> Alexander Lakhin writes:
>> 14.07.2018 13:57, Peter Eisentraut wrote:
>>> On 06.07.18 09:45, Alexander Lakhin wrote:
./configure --enable-tap-tests
make install
make install -C contrib
chown -R postgres:postgres /usr/local/pgsql/
I wrote:
> The original complaint about ecpg remains; I'm not terribly excited
> about messing with that.
Well, I got curious as to why we were seeing such a weird error,
and eventually traced it to this stuff in ecpg/test/Makefile.regress:
# Standard way to invoke the ecpg preprocessor
ECPG = ..
Alexander Lakhin writes:
> 14.07.2018 13:57, Peter Eisentraut wrote:
>> On 06.07.18 09:45, Alexander Lakhin wrote:
>>> ./configure --enable-tap-tests
>>> make install
>>> make install -C contrib
>>> chown -R postgres:postgres /usr/local/pgsql/
>>> /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/da
Hello Peter,
14.07.2018 13:57, Peter Eisentraut wrote:
> On 06.07.18 09:45, Alexander Lakhin wrote:
>> ./configure --enable-tap-tests
>> make install
>> make install -C contrib
>> chown -R postgres:postgres /usr/local/pgsql/
>> /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
>> /usr/local/pgsq
On 06.07.18 09:45, Alexander Lakhin wrote:
> ./configure --enable-tap-tests
> make install
> make install -C contrib
> chown -R postgres:postgres /usr/local/pgsql/
> /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
> /usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
> /make
Hello Tom,
11.07.2018 23:15, Tom Lane wrote:
>
>> /make clean/
>> # Also you can just install binary packages to get the same state.
>> make installcheck-world
>> # This check fails.
> I do not think that should be expected to work. It would require that
> "make installcheck" first invoke "make a
Alexander Lakhin writes:
> 06.07.2018 00:39, Peter Eisentraut wrote:
>> Exactly what order of steps are you executing that doesn't work?
> In Centos 7, using the master branch from git:
> ./configure --enable-tap-tests
> make install
> make install -C contrib
> chown -R postgres:postgres /usr/loc
Hello Peter,
06.07.2018 00:39, Peter Eisentraut wrote:
> Exactly what order of steps are you executing that doesn't work?
In Centos 7, using the master branch from git:
./configure --enable-tap-tests
make install
make install -C contrib
chown -R postgres:postgres /usr/local/pgsql/
/usr/local/pgsql/
Exactly what order of steps are you executing that doesn't work?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
07.05.2018 20:07, Tom Lane wrote:
Robert Haas writes:
After thinking about this some more, I think the question here is
definitional. A first attempt at defining 'make installcheck' is to
say that it runs the tests from the build tree against the running
server. Certainly, we intend to use th
Robert Haas writes:
> On Fri, May 4, 2018 at 8:30 AM, Alexander Lakhin wrote:
>> I'm not seeing a workaround to perform more complete installcheck without
>> modifying makefiles. So for me the question is whether the increasing the
>> testing surface justifies this use of time.
> After thinking
On Fri, May 4, 2018 at 8:30 AM, Alexander Lakhin wrote:
> I'm not seeing a workaround to perform more complete installcheck without
> modifying makefiles. So for me the question is whether the increasing the
> testing surface justifies this use of time.
After thinking about this some more, I thin
04.05.2018 14:58, Robert Haas wrote:
Thanks for your involvement!
Your proposed fix involves inventing something called
USE_INSTALLED_ASSETS, but we don't need that anywhere else, so why do
we need it for ECPG?
We need that not only for ECPG, but for libpostgres, libpgport, and
libpq too, if w
On Mon, Apr 2, 2018 at 5:12 AM, Alexander Lakhin wrote:
> Is it a supported scenario to make installcheck-world without performing
> "make" first?
The evidence suggests that the answer is "no".
> (If I do "make -C src/interfaces/ecpg" and then "make installcheck-world",
> then this error is gone
06.04.2018 09:19, Alexander Lakhin wrote:
To avoid overheating of this pretty hot discussion, I would like just
to propose "a more elaborated fix" (for REL_10_STABLE and master).
In fact, when we perform "make installcheck" it not only requires us
to build ecpg, but it also rebuilds libpostgres,
02.04.2018 12:12, Alexander Lakhin wrote:
Is it a supported scenario to make installcheck-world without
performing "make" first?
(If I do "make -C src/interfaces/ecpg" and then "make
installcheck-world", then this error is gone. And when I set up all
the extensions, all tests passed successfu
Hello,
I am trying to perform "make installcheck-world" after "make clean" (or
after installing a precompiled binaries), but it fails.
The error I get is related to ECPG regression test:
make -C test installcheck
make[2]: Entering directory
`/home/postgres/postgres/src/interfaces/ecpg/test'
gc
35 matches
Mail list logo
