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 thinking everything is fine.
>
> In prin
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 run through $PGDATA/pg
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 f
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_ dat
> 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 -na
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 arch
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 20
On Tue, Aug 18, 2015 at 3:32 PM, David Fetter 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 wrote:
> > > I'm given to understand that this tight coupling is necessary for
> > > performance. Are you saying that it could be
On Tue, Aug 18, 2015 at 02:03:19PM +0100, Greg Stark wrote:
> On Tue, Aug 18, 2015 at 6:57 AM, Noah Misch 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 your pg_reg
On Tue, Aug 18, 2015 at 04:54:07PM +0100, Greg Stark wrote:
> On Tue, Aug 18, 2015 at 2:16 PM, David Fetter 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
On Tue, Aug 18, 2015 at 2:16 PM, David Fetter 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 shouldn't expect to fi
On Tue, Aug 18, 2015 at 02:03:19PM +0100, Greg Stark wrote:
> On Tue, Aug 18, 2015 at 6:57 AM, Noah Misch wrote:
> >> I suspect any effort to significantly improve Postgres test
> >> coverage is doomed until there's an alternative to pg_regress.
> >
> > There is the src/test/perl/TestLib.pm harne
On Tue, Aug 18, 2015 at 6:57 AM, Noah Misch 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 people put more
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 wrote:
> >>When I've just spent awhile implementing a behavior change, the test diffs
> >>are
> >>a comforting sight. They confirm that the test suite
On 8/16/15 8:48 AM, Greg Stark wrote:
On Sun, Aug 16, 2015 at 7:33 AM, Noah Misch 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
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 pres
On Sun, Aug 16, 2015 at 7:33 AM, Noah Misch 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
> stringent met
On Fri, Aug 14, 2015 at 12:47:49PM +0100, Simon Riggs wrote:
> On 13 August 2015 at 00:31, Robert Haas wrote:
> > On Wed, Aug 12, 2015 at 7:20 PM, Tom Lane wrote:
> > > We've talked about having some sort of second rank of tests that
> > > people wouldn't necessarily run before committing, and th
On Wed, Aug 12, 2015 at 06:46:19PM +0100, Greg Stark wrote:
> On Wed, Aug 12, 2015 at 3:10 AM, Noah Misch 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 p
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: https:/
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
On 13 August 2015 at 00:31, Robert Haas wrote:
> On Wed, Aug 12, 2015 at 7:20 PM, Tom Lane 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 beha
On 8/13/15 1:31 AM, Peter Geoghegan wrote:
On Wed, Aug 12, 2015 at 11:23 PM, Magnus Hagander 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.
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 wrote:
Certainly don't mind at all, entirely open source under the MIT
license.
Why not the PG license? It would
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 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 have t
On 8/12/15 9:32 PM, Robert Haas wrote:
On Wed, Aug 12, 2015 at 9:24 PM, Stephen Frost 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 in the
works for th
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 tests
On Wed, Aug 12, 2015 at 11:23 PM, Magnus Hagander 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 worth the pr
On Thu, Aug 13, 2015 at 1:31 AM, Robert Haas wrote:
> On Wed, Aug 12, 2015 at 7:20 PM, Tom Lane 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
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 sec
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Aug 12, 2015 at 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:
On Wed, Aug 12, 2015 at 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
* 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
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 a
On Wed, Aug 12, 2015 at 7:20 PM, Tom Lane 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 IMO). I still
Robert Haas writes:
> On Wed, Aug 12, 2015 at 2:04 PM, Peter Geoghegan 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
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Aug 12, 2015 at 2:04 PM, Peter Geoghegan 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 thin
On Wed, Aug 12, 2015 at 2:04 PM, Peter Geoghegan 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 simply be more i
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 a
On Wed, Aug 12, 2015 at 10:46 AM, Greg Stark 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 extensive tes
On Wed, Aug 12, 2015 at 3:10 AM, Noah Misch 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
> principles for
On 12 August 2015 at 03:10, Noah Misch 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 we are not
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 mea
On 10 August 2015 at 13:55, Robert Haas wrote:
> On Mon, Aug 10, 2015 at 2:02 AM, Simon Riggs
> 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 func
On Mon, Aug 10, 2015 at 2:02 AM, 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 test
On 8 August 2015 at 17:47, Noah Misch 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
> objections
On Sat, Aug 8, 2015 at 8: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
The larger expense in having extensive test suites is the cost to
maintain them. With our current te
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 the
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 co
On Sat, Aug 8, 2015 at 9:47 AM, Noah Misch 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
> objections
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 up
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
the
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 cygwin
Alvaro Herrera 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 defining these constants so
On 16/04/2014 17:14, Alvaro Herrera wrote:
Marco Atzeri wrote:
On 13/04/2014 18:09, Tom Lane wrote:
Andres Freund 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. getad
Marco Atzeri wrote:
> On 13/04/2014 18:09, Tom Lane wrote:
> >Andres Freund 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:
> >>
On 13/04/2014 18:09, Tom Lane wrote:
Andres Freund 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
David Fetter 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 distributi
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 writes:
> > > > psql: conditionally display oids and replication identity
> > >
> > > Buildfarm isn'
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 writes:
> > > psql: conditionally display oids and replication identity
> >
> > Buildfarm isn't terribly pleased with this --- looks like you missed
> > con
Andres Freund 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 & NI_NAMEREQD)
>
On 2014-04-12 16:35:48 -0400, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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 numeric address fiel
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. f33a71a7865a1dd54f04b370e2637f88665f8d
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
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, fe
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
Date: Thu Apr 10 17:16:22 2014 -0400
docs: psql '--' comments are not passed to the server
C-style b
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 Devel
Anyone seeing similar failure ?
testing on latest
$ git log |head
commit 3c41b812c5578fd7bd5c2de42941012d7d56dde2
Author: Bruce Momjian
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 the server.
$ ca
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"
"Hiroshi Saito" writes:
[ examples_win32_patch2 ]
Is the addition of -DFRONTEND
"Hiroshi Saito" 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.
regards, tom lane
--
Sent
2009/12/30 Hiroshi Saito :
> 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 pgsql-hackers mailing li
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"
Hiroshi Saito wrote:
Hi Andrew-san.
Althou
Andrew Dunstan 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 src/Makefile.glo
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
+ #includ
uot;
Cc: "Hiroshi Saito" ; "Alvaro Herrera"
; "pgsql-hackers" ; "Bruce
Momjian"
Sent: Thursday, December 31, 2009 12:45 AM
Subject: Re: [HACKERS] test/example does not support win32.
Tom Lane wrote:
"Hiroshi Saito" writes:
Yes, I thi
Tom Lane wrote:
"Hiroshi Saito" 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 th
Bruce Momjian 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.
regards, tom
Tom Lane wrote:
> "Hiroshi Saito" 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 cod
"Hiroshi Saito" 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 evasion method
> of
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?
Regards,
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 Her
Hi Tom-san.
Um, How do you consider sample which cannot build?
Regards,
Hiroshi Saito
- Original Message -
From: "Tom Lane"
"Hiroshi Saito" writes:
test/example does not support win32.
The proposed added #includes seem quite inappropriate. postgres_fe.h
is meant for PG-proj
"Hiroshi Saito" 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
--
Sent via pgsql-hackers
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
test
maosen
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 ru
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 pgsql
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 ann
test
---(end of broadcast)---
TIP 6: explain analyze is your friend
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.
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,
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 -ha
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 t
-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
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
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 I
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, vmstat
Ü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
> d
Hi Robert (small world, I contributed to Sequoia a while ago...), all,
On 11/6/07, Robert Hodges <[EMAIL PROTECTED]> wrote:
> 2.) Test hardware. We have a number of hosts in Grenoble, France that are
> available to help set up a European lab.We gave away 4 to the
> postgresql.fr folks but if
1 - 100 of 208 matches
Mail list logo
