Re: [HACKERS] Test "tablespace" fails during `make installcheck` on master-replica setup

On Thu, Dec 8, 2016 at 12:06 AM, Tom Lane wrote: > Stephen Frost writes: >> It would be really nice if we would detect that some other postmaster is >> already using a given tablespace directory and to throw an error and >> complain rather than starting up

Re: [HACKERS] Test "tablespace" fails during `make installcheck` on master-replica setup

Stephen Frost writes: > It would be really nice if we would detect that some other postmaster is > already using a given tablespace directory and to throw an error and > complain rather than starting up thinking everything is fine. In principle, we could have the postmaster

Re: [HACKERS] Test "tablespace" fails during `make installcheck` on master-replica setup

Michael, all, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Wed, Dec 07, 2016 at 03:42:53PM +0300, Aleksander Alekseev wrote: > > > In the same host, primary and standby will try to use the tablespace > > > in the same path. That's the origin of this breakage. > > > > Sorry, I don't

Re: [HACKERS] Test "tablespace" fails during `make installcheck` on master-replica setup

On Wed, Dec 07, 2016 at 03:42:53PM +0300, Aleksander Alekseev wrote: > > In the same host, primary and standby will try to use the tablespace > > in the same path. That's the origin of this breakage. > > Sorry, I don't follow. Don't master and replica use different > directories to store _all_

Re: [HACKERS] Test "tablespace" fails during `make installcheck` on master-replica setup

> In the same host, primary and standby will try to use the tablespace > in the same path. That's the origin of this breakage. Sorry, I don't follow. Don't master and replica use different directories to store _all_ data? Particularly in my case: ``` $ find path/to/postgresql-install/ -type d

Re: [HACKERS] Test "tablespace" fails during `make installcheck` on master-replica setup

On Wed, Dec 07, 2016 at 03:18:59PM +0300, Aleksander Alekseev wrote: > I noticed, that `make installcheck` fails on my laptop with following > errors: > > http://afiskon.ru/s/98/6f94ce2cfa_regression.out.txt > http://afiskon.ru/s/b3/d0da05597e_regression.diffs.txt The interesting bit for the

[HACKERS] Test "tablespace" fails during `make installcheck` on master-replica setup

Hello. I noticed, that `make installcheck` fails on my laptop with following errors: http://afiskon.ru/s/98/6f94ce2cfa_regression.out.txt http://afiskon.ru/s/b3/d0da05597e_regression.diffs.txt My first idea was to use `git bisect`. It turned out that this issue reproduces on commits back from

Re: [HACKERS] Test code is worth the space

On Tue, Aug 18, 2015 at 02:03:19PM +0100, Greg Stark wrote: On Tue, Aug 18, 2015 at 6:57 AM, Noah Misch n...@leadboat.com wrote: My own position is based on having maintained a pg_regress suite an order of magnitude larger than that. I don't know why that outcome was so different. And does

Re: [HACKERS] Test code is worth the space

On Tue, Aug 18, 2015 at 3:32 PM, David Fetter da...@fetter.org wrote: On Tue, Aug 18, 2015 at 04:54:07PM +0100, Greg Stark wrote: On Tue, Aug 18, 2015 at 2:16 PM, David Fetter da...@fetter.org wrote: I'm given to understand that this tight coupling is necessary for performance. Are you

Re: [HACKERS] Test code is worth the space

On Tue, Aug 18, 2015 at 02:03:19PM +0100, Greg Stark wrote: On Tue, Aug 18, 2015 at 6:57 AM, Noah Misch n...@leadboat.com wrote: I suspect any effort to significantly improve Postgres test coverage is doomed until there's an alternative to pg_regress. There is the

Re: [HACKERS] Test code is worth the space

On Tue, Aug 18, 2015 at 6:57 AM, Noah Misch n...@leadboat.com wrote: My own position is based on having maintained a pg_regress suite an order of magnitude larger than that. I don't know why that outcome was so different. Comparing the size of test suites by these numbers is impossible because

Re: [HACKERS] Test code is worth the space

On Tue, Aug 18, 2015 at 04:54:07PM +0100, Greg Stark wrote: On Tue, Aug 18, 2015 at 2:16 PM, David Fetter da...@fetter.org wrote: I'm given to understand that this tight coupling is necessary for performance. Are you saying that it could be unwound, or that testing strategies mostly need

Re: [HACKERS] Test code is worth the space

On Tue, Aug 18, 2015 at 2:16 PM, David Fetter da...@fetter.org wrote: I'm given to understand that this tight coupling is necessary for performance. Are you saying that it could be unwound, or that testing strategies mostly need to take it into account, or...? I'm just saying that we

Re: [HACKERS] Test code is worth the space

On Mon, Aug 17, 2015 at 02:04:40PM -0500, Jim Nasby wrote: On 8/16/15 8:48 AM, Greg Stark wrote: On Sun, Aug 16, 2015 at 7:33 AM, Noah Misch n...@leadboat.com wrote: When I've just spent awhile implementing a behavior change, the test diffs are a comforting sight. They confirm that the test

Re: [HACKERS] Test code is worth the space

On 8/15/15 4:45 AM, Petr Jelinek wrote: We could fix a) by adding ORDER BY to those queries but I don't see how to fix the rest easily or at all without sacrificing some test coverage. Hopefully at some point we'll have test frameworks that don't depend on capturing raw psql output, which

Re: [HACKERS] Test code is worth the space

On 8/16/15 8:48 AM, Greg Stark wrote: On Sun, Aug 16, 2015 at 7:33 AM, Noah Misch n...@leadboat.com wrote: When I've just spent awhile implementing a behavior change, the test diffs are a comforting sight. They confirm that the test suite exercises the topic I just changed. Furthermore, most

Re: [HACKERS] Test code is worth the space

On Wed, Aug 12, 2015 at 06:46:19PM +0100, Greg Stark wrote: On Wed, Aug 12, 2015 at 3:10 AM, Noah Misch n...@leadboat.com wrote: Committers press authors to delete tests more often than we press them to resubmit with more tests. No wonder so many patches have insufficient tests; we

Re: [HACKERS] Test code is worth the space

On Fri, Aug 14, 2015 at 12:47:49PM +0100, Simon Riggs wrote: On 13 August 2015 at 00:31, Robert Haas robertmh...@gmail.com wrote: On Wed, Aug 12, 2015 at 7:20 PM, Tom Lane t...@sss.pgh.pa.us wrote: We've talked about having some sort of second rank of tests that people wouldn't

Re: [HACKERS] Test code is worth the space

On Sun, Aug 16, 2015 at 7:33 AM, Noah Misch n...@leadboat.com wrote: When I've just spent awhile implementing a behavior change, the test diffs are a comforting sight. They confirm that the test suite exercises the topic I just changed. Furthermore, most tests today do not qualify under this

Re: [HACKERS] Test code is worth the space

On 2015-08-15 03:35, Jim Nasby wrote: I setup a simple example of this with 64 variations of TAP tests, BLKSZ and WAL blocksize. Unfortunately to make this work you have to commit a .travis.yml file to your fork. build: https://travis-ci.org/decibel/postgres/builds/75692344 .travis.yml:

Re: [HACKERS] Test code is worth the space

On 13 August 2015 at 00:31, Robert Haas robertmh...@gmail.com wrote: On Wed, Aug 12, 2015 at 7:20 PM, Tom Lane t...@sss.pgh.pa.us wrote: FWIW, I've objected in the past to tests that would significantly increase the runtime of make check, unless I thought they were especially valuable

Re: [HACKERS] Test code is worth the space

On 8/14/15 12:11 AM, Jim Nasby wrote: I favor splitting the regression tests to add all the time and before commit targets as you describe. I think that once the facility is there, we can determine over time how expansive that second category gets to be. I don't know how many folks work in a

Re: [HACKERS] Test code is worth the space

On Thu, Aug 13, 2015 at 1:31 AM, Robert Haas robertmh...@gmail.com wrote: On Wed, Aug 12, 2015 at 7:20 PM, Tom Lane t...@sss.pgh.pa.us wrote: FWIW, I've objected in the past to tests that would significantly increase the runtime of make check, unless I thought they were especially valuable

Re: [HACKERS] Test code is worth the space

FWIW, I've objected in the past to tests that would significantly increase the runtime of make check, unless I thought they were especially valuable (which enumerating every minor behavior of a feature patch generally isn't IMO). I still think that that's an important consideration: every

Re: [HACKERS] Test code is worth the space

On Wed, Aug 12, 2015 at 11:23 PM, Magnus Hagander mag...@hagander.net wrote: The value of a core regression suite that takes less time to run has to be weighed against the possibility that a better core regression suite might cause us to find more bugs before committing. That could easily be

Re: [HACKERS] Test code is worth the space

On 8/12/15 9:24 PM, Stephen Frost wrote: * Michael Paquier (michael.paqu...@gmail.com) wrote: On Thu, Aug 13, 2015 at 5:54 AM, Stephen Frost wrote: The regression tests included in pgBackRest (available here: https://github.com/pgmasters/backrest) go through a number of different recovery

Re: [HACKERS] Test code is worth the space

On 2015-08-13 09:32:02 -0400, David Steele wrote: On 8/12/15 9:32 PM, Robert Haas wrote: On Wed, Aug 12, 2015 at 9:24 PM, Stephen Frost sfr...@snowman.net wrote: Certainly don't mind at all, entirely open source under the MIT license. Why not the PG license? It would be nicer if we didn't

Re: [HACKERS] Test code is worth the space

On 8/12/15 9:32 PM, Robert Haas wrote: On Wed, Aug 12, 2015 at 9:24 PM, Stephen Frost sfr...@snowman.net wrote: * Michael Paquier (michael.paqu...@gmail.com) wrote: Interesting. Do you mind if I pick up from it some ideas for the in-core replication test suite based on TAP stuff? That's still

Re: [HACKERS] Test code is worth the space

On 8/13/15 9:55 AM, Andres Freund wrote: On 2015-08-13 09:32:02 -0400, David Steele wrote: On 8/12/15 9:32 PM, Robert Haas wrote: On Wed, Aug 12, 2015 at 9:24 PM, Stephen Frost sfr...@snowman.net wrote: Certainly don't mind at all, entirely open source under the MIT license. Why not the PG

Re: [HACKERS] Test code is worth the space

On 8/13/15 1:31 AM, Peter Geoghegan wrote: On Wed, Aug 12, 2015 at 11:23 PM, Magnus Hagander mag...@hagander.net wrote: The value of a core regression suite that takes less time to run has to be weighed against the possibility that a better core regression suite might cause us to find more bugs

Re: [HACKERS] Test code is worth the space

* Robert Haas (robertmh...@gmail.com) wrote: On Wed, Aug 12, 2015 at 2:04 PM, Peter Geoghegan p...@heroku.com wrote: This resistance to adding tests seems quite short sighted to me, especially when the concern is about queries that will each typically take less than 1ms to execute. Like

Re: [HACKERS] Test code is worth the space

On Wed, Aug 12, 2015 at 7:20 PM, Tom Lane t...@sss.pgh.pa.us wrote: FWIW, I've objected in the past to tests that would significantly increase the runtime of make check, unless I thought they were especially valuable (which enumerating every minor behavior of a feature patch generally isn't

Re: [HACKERS] Test code is worth the space

Robert Haas robertmh...@gmail.com writes: On Wed, Aug 12, 2015 at 2:04 PM, Peter Geoghegan p...@heroku.com wrote: This resistance to adding tests seems quite short sighted to me, especially when the concern is about queries that will each typically take less than 1ms to execute. Like Noah, I

Re: [HACKERS] Test code is worth the space

On Wed, Aug 12, 2015 at 2:04 PM, Peter Geoghegan p...@heroku.com wrote: This resistance to adding tests seems quite short sighted to me, especially when the concern is about queries that will each typically take less than 1ms to execute. Like Noah, I think that it would be very helpful to

Re: [HACKERS] Test code is worth the space

On Thu, Aug 13, 2015 at 5:54 AM, Stephen Frost wrote: The regression tests included in pgBackRest (available here: https://github.com/pgmasters/backrest) go through a number of different recovery tests. There's vagrant configs for a few different VMs too (CentOS 6, CentOS 7, Ubuntu 12.04 and

Re: [HACKERS] Test code is worth the space

On Wed, Aug 12, 2015 at 9:24 PM, Stephen Frost sfr...@snowman.net wrote: * Michael Paquier (michael.paqu...@gmail.com) wrote: On Thu, Aug 13, 2015 at 5:54 AM, Stephen Frost wrote: The regression tests included in pgBackRest (available here: https://github.com/pgmasters/backrest) go through a

Re: [HACKERS] Test code is worth the space

* Michael Paquier (michael.paqu...@gmail.com) wrote: On Thu, Aug 13, 2015 at 5:54 AM, Stephen Frost wrote: The regression tests included in pgBackRest (available here: https://github.com/pgmasters/backrest) go through a number of different recovery tests. There's vagrant configs for a few

Re: [HACKERS] Test code is worth the space

* Robert Haas (robertmh...@gmail.com) wrote: On Wed, Aug 12, 2015 at 9:24 PM, Stephen Frost sfr...@snowman.net wrote: * Michael Paquier (michael.paqu...@gmail.com) wrote: On Thu, Aug 13, 2015 at 5:54 AM, Stephen Frost wrote: The regression tests included in pgBackRest (available here:

Re: [HACKERS] Test code is worth the space

On 12 August 2015 at 03:10, Noah Misch n...@leadboat.com wrote: On another review I suggested we add a function to core to allow it to be used in regression tests. A long debate ensued, deciding that we must be consistent and put diagnostic functions in contrib. My understanding is that

Re: [HACKERS] Test code is worth the space

On Wed, Aug 12, 2015 at 10:46 AM, Greg Stark st...@mit.edu wrote: The only time I've seen pushback against tests is when the test author made valiant efforts to test every codepath and the expected output embeds the precise behaviour of the current code as correct. Even when patches have

Re: [HACKERS] Test code is worth the space

On Wed, Aug 12, 2015 at 3:10 AM, Noah Misch n...@leadboat.com wrote: Committers press authors to delete tests more often than we press them to resubmit with more tests. No wonder so many patches have insufficient tests; we treat those patches more favorably, on average. I have no objective

Re: [HACKERS] Test code is worth the space

One trouble I face when adding tests is that sometimes they require hooks in the code, to test for race conditions. In BRIN I cannot test some code paths without resorting to adding breakpoints in GDB, for instance. If there's no support for such in the core code, it's essentially impossible to

Re: [HACKERS] Test code is worth the space

On Mon, Aug 10, 2015 at 07:02:17AM +0100, Simon Riggs wrote: Almost every patch I review has either zero or insufficient tests. If we care about robustness, then we must discuss tests. Here are my two recent experiences: I agree we could do with x10 as many tests, but that doesn't mean all

Re: [HACKERS] Test code is worth the space

On Mon, Aug 10, 2015 at 2:02 AM, Simon Riggs si...@2ndquadrant.com wrote: Almost every patch I review has either zero or insufficient tests. If we care about robustness, then we must discuss tests. Here are my two recent experiences: I agree we could do with x10 as many tests, but that

Re: [HACKERS] Test code is worth the space

On 8 August 2015 at 17:47, Noah Misch n...@leadboat.com wrote: We've too often criticized patches for carrying many lines/bytes of test case additions. Let's continue to demand debuggable, secure tests that fail only when something is wrong, but let's stop pushing for test minimalism. Such

Re: [HACKERS] Test code is worth the space

On 10 August 2015 at 13:55, Robert Haas robertmh...@gmail.com wrote: On Mon, Aug 10, 2015 at 2:02 AM, Simon Riggs si...@2ndquadrant.com wrote: On another review I suggested we add a function to core to allow it to be used in regression tests. A long debate ensued, deciding that we must be

[HACKERS] Test code is worth the space

We've too often criticized patches for carrying many lines/bytes of test case additions. Let's continue to demand debuggable, secure tests that fail only when something is wrong, but let's stop pushing for test minimalism. Such objections may improve the individual patch, but that doesn't make

Re: [HACKERS] Test code is worth the space

On Sat, Aug 8, 2015 at 9:47 AM, Noah Misch n...@leadboat.com wrote: We've too often criticized patches for carrying many lines/bytes of test case additions. Let's continue to demand debuggable, secure tests that fail only when something is wrong, but let's stop pushing for test minimalism.

Re: [HACKERS] Test code is worth the space

On 08/08/2015 12:24 PM, Peter Geoghegan wrote: I think that there needs to be a way of running an extended set of regression tests. I could definitely respect the desire for minimalism when it comes to adding tests to the regression tests proper if there was an extended set of tests that could

Re: [HACKERS] Test code is worth the space

On 08/08/2015 05:09 PM, Josh Berkus wrote: On 08/08/2015 12:24 PM, Peter Geoghegan wrote: I think that there needs to be a way of running an extended set of regression tests. I could definitely respect the desire for minimalism when it comes to adding tests to the regression tests proper if

Re: [HACKERS] Test code is worth the space

On Sat, Aug 8, 2015 at 8:24 PM, Peter Geoghegan p...@heroku.com wrote: I think that there needs to be a way of running an extended set of regression tests. I could definitely respect the desire for minimalism The larger expense in having extensive test suites is the cost to maintain them. With

Re: [HACKERS] test failure on latest source

On 16/04/2014 18:55, Marco Atzeri wrote: On 16/04/2014 17:40, Tom Lane wrote: The bigger picture though is that this code isn't failing on the buildfarm. So what we need to ask is what's different about Marco's machine. good question. I checked again and I found that the fault is only on

Re: [HACKERS] test failure on latest source

On 13/04/2014 18:09, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-04-12 16:35:48 -0400, Tom Lane wrote: In principle, that commit shouldn't have affected behavior for pg_hba entries with numeric address fields ... Hm. getaddrinfo.c has this bit: /*

Re: [HACKERS] test failure on latest source

Marco Atzeri wrote: On 13/04/2014 18:09, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-04-12 16:35:48 -0400, Tom Lane wrote: In principle, that commit shouldn't have affected behavior for pg_hba entries with numeric address fields ... Hm. getaddrinfo.c has this bit:

Re: [HACKERS] test failure on latest source

On 16/04/2014 17:14, Alvaro Herrera wrote: Marco Atzeri wrote: On 13/04/2014 18:09, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-04-12 16:35:48 -0400, Tom Lane wrote: In principle, that commit shouldn't have affected behavior for pg_hba entries with numeric address

Re: [HACKERS] test failure on latest source

Alvaro Herrera alvhe...@2ndquadrant.com writes: I don't know if this is relevant, but perhaps we're defining the constants in a way that conflicts with the values defined by cygwin. Hm, that's a thought, though I still don't see how it's relevant to the reported failure. Perhaps Cygwin is

Re: [HACKERS] test failure on latest source

On 16/04/2014 17:40, Tom Lane wrote: The bigger picture though is that this code isn't failing on the buildfarm. So what we need to ask is what's different about Marco's machine. good question. I checked again and I found that the fault is only on the cygwin 64 bit build but not on the

[HACKERS] test script, was Re: [COMMITTERS] pgsql: psql: conditionally display oids and replication identity

On Tue, Apr 15, 2014 at 02:46:34PM -0400, Bruce Momjian wrote: On Tue, Apr 15, 2014 at 02:32:53PM -0400, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: psql: conditionally display oids and replication identity Buildfarm isn't terribly pleased with this --- looks like you missed

Re: [HACKERS] test script, was Re: [COMMITTERS] pgsql: psql: conditionally display oids and replication identity

On 2014-04-15 12:32:36 -0700, David Fetter wrote: On Tue, Apr 15, 2014 at 02:46:34PM -0400, Bruce Momjian wrote: On Tue, Apr 15, 2014 at 02:32:53PM -0400, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: psql: conditionally display oids and replication identity Buildfarm

Re: [HACKERS] test script, was Re: [COMMITTERS] pgsql: psql: conditionally display oids and replication identity

David Fetter da...@fetter.org writes: On Tue, Apr 15, 2014 at 02:46:34PM -0400, Bruce Momjian wrote: Fixed. I added a personal script option that allows me to test contrib, but forgot to run it. Is that script of general utility for committers? If so, it might be good to include it in the

Re: [HACKERS] test failure on latest source

On 2014-04-12 16:35:48 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-04-12 19:45:59 +0200, Marco Atzeri wrote: so it is only failing on recent trunk Does it work on a commit before fc752505a99a4e2c781a070d3d42a25289c22e3c? In principle, that commit

Re: [HACKERS] test failure on latest source

Andres Freund and...@2ndquadrant.com writes: On 2014-04-12 16:35:48 -0400, Tom Lane wrote: In principle, that commit shouldn't have affected behavior for pg_hba entries with numeric address fields ... Hm. getaddrinfo.c has this bit: /* Unsupported flags. */ if (flags

[HACKERS] test failure on latest source

Anyone seeing similar failure ? testing on latest $ git log |head commit 3c41b812c5578fd7bd5c2de42941012d7d56dde2 Author: Bruce Momjian br...@momjian.us Date: Thu Apr 10 17:16:22 2014 -0400 docs: psql '--' comments are not passed to the server C-style block comments are passed to

Re: [HACKERS] test failure on latest source

On 2014-04-12 18:39:54 +0200, Marco Atzeri wrote: LOG: invalid IP address 127.0.0.1: Non-recoverable failure in name resolution That sounds like a local setup problem. Is 127.0.0.1 pingable? Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] test failure on latest source

On 04/12/2014 12:39 PM, Marco Atzeri wrote: Anyone seeing similar failure ? testing on latest $ git log |head commit 3c41b812c5578fd7bd5c2de42941012d7d56dde2 Author: Bruce Momjian br...@momjian.us Date: Thu Apr 10 17:16:22 2014 -0400 docs: psql '--' comments are not passed to the

Re: [HACKERS] test failure on latest source

On 12/04/2014 19:11, Andrew Dunstan wrote: Why can't it resolve localhost? That's a local issue you need to fix. cheers andrew Andrew, just to be clear - localhost is resolved to 127.0.0.1 - 127.0.0.1 is pingable - same test on 9.3.4 works All 135 tests passed. - same test, few

Re: [HACKERS] test failure on latest source

On 2014-04-12 19:45:59 +0200, Marco Atzeri wrote: On 12/04/2014 19:11, Andrew Dunstan wrote: Why can't it resolve localhost? That's a local issue you need to fix. cheers andrew Andrew, just to be clear - localhost is resolved to 127.0.0.1 - 127.0.0.1 is pingable - same

Re: [HACKERS] test failure on latest source

On 12/04/2014 19:48, Andres Freund wrote: On 2014-04-12 19:45:59 +0200, Marco Atzeri wrote: - same test, few days ago, on trunk was fine so it is only failing on recent trunk Does it work on a commit before fc752505a99a4e2c781a070d3d42a25289c22e3c? E.g.

Re: [HACKERS] test failure on latest source

Andres Freund and...@2ndquadrant.com writes: On 2014-04-12 19:45:59 +0200, Marco Atzeri wrote: so it is only failing on recent trunk Does it work on a commit before fc752505a99a4e2c781a070d3d42a25289c22e3c? In principle, that commit shouldn't have affected behavior for pg_hba entries with

Re: [HACKERS] test/example does not support win32.

Hiroshi Saito wrote: Hi Tom-san. Um, How do you consider sample which cannot build? I think testlibpq2.c is missing a couple of system includes, sys/types.h and unistd.h (or alternatively select.h); and testlibpq3.c is missing stdint.h. Or so say my (POSIX) manpages anyway. -- Alvaro

Re: [HACKERS] test/example does not support win32.

Hi Alvaro-san. Yes, I thinks that it is an exact idea. However, this example was not helped. fd_set complains Thanks! It seems that pg_bench takes the thing same again into consideration. Anyway, If it is called example of end-user code, what is the evasion method of fd_set?

Re: [HACKERS] test/example does not support win32.

Hiroshi Saito z-sa...@guitar.ocn.ne.jp writes: Yes, I thinks that it is an exact idea. However, this example was not helped. fd_set complains Thanks! It seems that pg_bench takes the thing same again into consideration. Anyway, If it is called example of end-user code, what is the

Re: [HACKERS] test/example does not support win32.

Tom Lane wrote: Hiroshi Saito z-sa...@guitar.ocn.ne.jp writes: Yes, I thinks that it is an exact idea. However, this example was not helped. fd_set complains Thanks! It seems that pg_bench takes the thing same again into consideration. Anyway, If it is called example of

Re: [HACKERS] test/example does not support win32.

Bruce Momjian br...@momjian.us writes: Well, those example programs are pretty clean libpq apps so I don't see why they should using platform-specific stuff. Example #2 depends on select(), which depends on fd_set, so you're already into territory where there are issues.

Re: [HACKERS] test/example does not support win32.

Tom Lane wrote: Hiroshi Saito z-sa...@guitar.ocn.ne.jp writes: Yes, I thinks that it is an exact idea. However, this example was not helped. fd_set complains Thanks! It seems that pg_bench takes the thing same again into consideration. Anyway, If it is called example of

Re: [HACKERS] test/example does not support win32.

Dunstan and...@dunslane.net To: Tom Lane t...@sss.pgh.pa.us Cc: Hiroshi Saito z-sa...@guitar.ocn.ne.jp; Alvaro Herrera alvhe...@commandprompt.com; pgsql-hackers pgsql-hackers@postgresql.org; Bruce Momjian br...@momjian.us Sent: Thursday, December 31, 2009 12:45 AM Subject: Re: [HACKERS] test

Re: [HACKERS] test/example does not support win32.

Hiroshi Saito wrote: Hi Andrew-san. Although this is a standard in windows. *** testlibpq2.c.orig Wed Dec 30 13:19:03 2009 --- testlibpq2.cThu Dec 31 00:52:52 2009 *** *** 24,34 --- 24,39 * * INSERT INTO TBL1 VALUES (10); */ + + #ifdef WIN32 +

Re: [HACKERS] test/example does not support win32.

Andrew Dunstan and...@dunslane.net writes: Tom Lane wrote: On reflection I think it's just wrong to expect that the examples will compile out-of-the-box on every platform. That would be all good and well if we didn't already rely on the configure setup. But we do - the Makefile includes

Re: [HACKERS] test/example does not support win32.

Hi Andrew-san. This saves a windows users. I appreciate your suggestion. Thanks! P.S) I often use by the test by nmake at the time of independent creation of libpq. Regards, Hiroshi Saito - Original Message - From: Andrew Dunstan and...@dunslane.net Hiroshi Saito wrote: Hi

Re: [HACKERS] test/example does not support win32.

2009/12/30 Hiroshi Saito z-sa...@guitar.ocn.ne.jp: Hi Andrew-san. This saves a windows users. I appreciate your suggestion. Thanks! This one looks much better. +1 for this version :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via

Re: [HACKERS] test/example does not support win32.

Hiroshi Saito z-sa...@guitar.ocn.ne.jp writes: [ examples_win32_patch2 ] Is the addition of -DFRONTEND actually needed, and if so why? We shouldn't be depending on that in any user-exposed code, I would think. Otherwise I don't have any objection to this version.

Re: [HACKERS] test/example does not support win32.

Hi Tom-san. Ahh.. It was correction of the test of often... again, the pursued relation was seen, I think that it is good now. Thanks!! Regards, Hiroshi Saito - Original Message - From: Tom Lane t...@sss.pgh.pa.us Hiroshi Saito z-sa...@guitar.ocn.ne.jp writes: [

[HACKERS] test/example does not support win32.

Hi. test/example does not support win32. Although I posted also in the past, I am slightly persistent. I think whether it also needs correction of a document. == CVS-HEAD on as for MinGW + gcc == testlibpq2.c: In function `main': testlibpq2.c:98: error: `fd_set' undeclared (first use in this

Re: [HACKERS] test/example does not support win32.

Hiroshi Saito z-sa...@guitar.ocn.ne.jp writes: test/example does not support win32. The proposed added #includes seem quite inappropriate. postgres_fe.h is meant for PG-project code, it is not supposed to have to be included by all end-user code. regards, tom lane --

Re: [HACKERS] test/example does not support win32.

Hi Tom-san. Um, How do you consider sample which cannot build? Regards, Hiroshi Saito - Original Message - From: Tom Lane t...@sss.pgh.pa.us Hiroshi Saito z-sa...@guitar.ocn.ne.jp writes: test/example does not support win32. The proposed added #includes seem quite

[HACKERS] test

test maosen

Re: [HACKERS] test

Andrew Hammond wrote: On Dec 12, 2007 11:37 AM, Alvaro Herrera [EMAIL PROTECTED] wrote: Joshua D. Drake wrote: test Does anybody see any value in having [EMAIL PROTECTED] be an alias for pgsql-hackers? No, but I see some mild irritation in having to modify my rules to tag a

[HACKERS] test

test ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [HACKERS] test

Joshua D. Drake wrote: test Does anybody see any value in having [EMAIL PROTECTED] be an alias for pgsql-hackers? -- Alvaro Herrera http://www.flickr.com/photos/alvherre/ Postgres is bloatware by design: it was built to house PhD theses. (Joey Hellerstein, SIGMOD

Re: [HACKERS] test

On Dec 12, 2007 11:37 AM, Alvaro Herrera [EMAIL PROTECTED] wrote: Joshua D. Drake wrote: test Does anybody see any value in having [EMAIL PROTECTED] be an alias for pgsql-hackers? No, but I see some mild irritation in having to modify my rules to tag a second address with the

Re: [HACKERS] Test lab

On Thu, 2007-11-22 at 22:29 +, Heikki Linnakangas wrote: Simon Riggs wrote: I'm thinking of some performance regression testing to see what else is lurking around the corner for us. If you have something you can just throw over the fence, I can run stuff on Imola as well. Thanks,

Re: [HACKERS] Test lab

On Thu, 2007-11-08 at 13:34 -0800, Joshua D. Drake wrote: On Sun, 04 Nov 2007 18:55:59 + Simon Riggs [EMAIL PROTECTED] wrote: ve up and have ready access to is a HP DL 585. It has 8 cores (Opteron), 32GB of ram and 28 spindles over 4 channels. My question is -hackers, is who

Re: [HACKERS] Test lab

Simon Riggs wrote: On Thu, 2007-11-08 at 13:34 -0800, Joshua D. Drake wrote: On Sun, 04 Nov 2007 18:55:59 + Simon Riggs [EMAIL PROTECTED] wrote: ve up and have ready access to is a HP DL 585. It has 8 cores (Opteron), 32GB of ram and 28 spindles over 4 channels. My question is -hackers,

Re: [HACKERS] Test lab

On Sun, 4 Nov 2007, Stefan Kaltenbrunner wrote: I never got the database tests in SysBench to produce useful results [because of deadlocks] hmm I have not seen that and the recent freebsd related scalability benchmarks(http://people.freebsd.org/~kris/scaling/) seem to indicate that it seems

Re: [HACKERS] Test lab

Joshua D. Drake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, The test lab is finally starting to come to fruition. We (the community) have been donated hardware via MyYearbook and Hi5. It is my understanding that we may also have some coming from HP. Also, from Sun, and from

Re: [HACKERS] Test lab

On Sun, 2007-11-04 at 18:55 +, Simon Riggs wrote: On Fri, 2007-11-02 at 10:42 -0700, Joshua D. Drake wrote: My question is -hackers, is who wants first bite and what do they want :) I'll take a few slots, probably 3 x 1 days, at least a week apart. Won't be able to start before

Re: [HACKERS] Test lab

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 04 Nov 2007 18:55:59 + Simon Riggs [EMAIL PROTECTED] wrote: ve up and have ready access to is a HP DL 585. It has 8 cores (Opteron), 32GB of ram and 28 spindles over 4 channels. My question is -hackers, is who wants first bite and

Re: [HACKERS] Test lab

On Wed, 7 Nov 2007, Hannu Krosing wrote: To be really useful, we should always run general system monitoring alongside DB test runs, so we can see, and also later look up, where the bottleneck are. The way the DBT-2 tests run involves spawning off the relevant monitoring tools (iostat,

Re: [HACKERS] Test lab

Ühel kenal päeval, P, 2007-11-04 kell 13:02, kirjutas Greg Smith: On Sat, 3 Nov 2007, Stefan Kaltenbrunner wrote: there is the various dbt workloads,sysbench, jans tpc-w implementation, hell even pgbench The DBT workloads are good for simulating disk-bound operations, but I don't

Re: [HACKERS] Test lab

On Mon, 2007-11-05 at 14:33 -0800, Mark Wong wrote: On 11/4/07, Simon Riggs [EMAIL PROTECTED] wrote: Why don't you post a TODO list for TPC-E somewhere, so people can bite small pieces off of the list. I'm sure there's lots of people can help if we do it that way. This should be a good

  1   2   3   >