Pavel Stehule writes:
>> 2016-11-21 8:09 GMT+01:00 Craig Ringer :
>>> Simple fix here is to append COLLATE "C" after the ORDER BY.
> here is a patch
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
2016-11-21 8:13 GMT+01:00 Pavel Stehule :
>
>
> 2016-11-21 8:09 GMT+01:00 Craig Ringer :
>
>> On 21 November 2016 at 14:45, Pavel Stehule
>> wrote:
>>
>> > SELECT (regexp_split_to_array(data, ':'))[4], COUNT(*),
>> > (array_agg(data))[1], (array_agg(data))[count(*)]
>> > FROM pg_logical_slot_g
2016-11-21 8:09 GMT+01:00 Craig Ringer :
> On 21 November 2016 at 14:45, Pavel Stehule
> wrote:
>
> > SELECT (regexp_split_to_array(data, ':'))[4], COUNT(*),
> > (array_agg(data))[1], (array_agg(data))[count(*)]
> > FROM pg_logical_slot_get_changes('regression_slot', NULL,NULL) WHERE
> data
>
On 21 November 2016 at 14:45, Pavel Stehule wrote:
> SELECT (regexp_split_to_array(data, ':'))[4], COUNT(*),
> (array_agg(data))[1], (array_agg(data))[count(*)]
> FROM pg_logical_slot_get_changes('regression_slot', NULL,NULL) WHERE data
> ~ 'INSERT'
> GROUP BY 1 ORDER BY 1;
>
> but result is
2016-11-16 5:54 GMT+01:00 Pavel Stehule :
> Hi
>
> I have a repeated problem with regress tests
>
> master, Fedora 25,
>
> running on port 50848 with PID 5548
> == creating database "regression" ==
> CREATE DATABASE
> ALTER DATABASE
> == running regressi
Hi
I have a repeated problem with regress tests
master, Fedora 25,
running on port 50848 with PID 5548
== creating database "regression" ==
CREATE DATABASE
ALTER DATABASE
== running regression test queries==
test ddl
On Mon, Jul 18, 2016 at 11:13 AM, Tom Lane wrote:
>> I don't particularly like your suggestion of spooky action at a
>> distance between force_parallel_mode and regression_test_mode. That
>> just seems kooky.
>
> It's certainly a judgment call as to which way is cleaner, but I don't
> understand
On Mon, Jul 18, 2016 at 1:34 AM, Michael Paquier
wrote:
> One downside of the plugin is that any users willing to do make
> installcheck would need to install it as well.
Not really. If the only purpose of the plugin is to verify that we're
not creating regression users whose names don't start w
Peter Eisentraut writes:
> On 7/15/16 6:13 PM, Tom Lane wrote:
>> We've talked before about how the regression tests should be circumspect
>> about what role names they create/drop, so as to avoid possibly blowing
>> up an installation's existing users during "make installcheck".
> I'm not partic
On 7/15/16 6:13 PM, Tom Lane wrote:
> We've talked before about how the regression tests should be circumspect
> about what role names they create/drop, so as to avoid possibly blowing
> up an installation's existing users during "make installcheck".
I'm not particularly sure that that is a useful
Robert Haas writes:
> On Sat, Jul 16, 2016 at 11:38 AM, Tom Lane wrote:
>> I'm coming to the conclusion that the only thing that will make this
>> materially better in the long run is automatic enforcement of a convention
>> about what role names may be created in the regression tests. See my
>>
On Mon, Jul 18, 2016 at 10:37 AM, Robert Haas wrote:
> On Sat, Jul 16, 2016 at 11:38 AM, Tom Lane wrote:
> We could also do this by loading a C module during the regression
> tests, which seems maybe less ugly than adding a GUC.
> I don't particularly like your suggestion of spooky action at a
>
On Sat, Jul 16, 2016 at 11:38 AM, Tom Lane wrote:
> I'm coming to the conclusion that the only thing that will make this
> materially better in the long run is automatic enforcement of a convention
> about what role names may be created in the regression tests. See my
> response to Stephen just n
I've gone ahead and pushed a patch that does all of the cosmetic renamings
needed to clean up the global-object-names situation. I've not done
anything yet about those special cases in the rolenames test, since it's
open for discussion exactly what to do there. I figured that this patch
was bulky
Alvaro Herrera writes:
> Tom Lane wrote:
>> We've talked before about how the regression tests should be circumspect
>> about what role names they create/drop, so as to avoid possibly blowing
>> up an installation's existing users during "make installcheck". In
>> particular I believe there was c
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> One could certainly argue that these are safe enough because nobody would
>> ever create real roles by those names anyway. I'm not very comfortable
>> with that though; if we believe that, why did we go to the trouble of
>> making
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> We've talked before about how the regression tests should be circumspect
> about what role names they create/drop, so as to avoid possibly blowing
> up an installation's existing users during "make installcheck". In
> particular I believe there was co
On 16 Jul 2016 12:59 pm, "Michael Paquier"
wrote:
>
> Thanks for doing this.
+1
Though I might highlight this as the kind of issue that a bug tracker would
help avoid falling through the cracks and make visible to newcomers.
> I am -1 for dropping the tests. We could just have a CFLAGS that ad
On Sat, Jul 16, 2016 at 7:13 AM, Tom Lane wrote:
> We've talked before about how the regression tests should be circumspect
> about what role names they create/drop, so as to avoid possibly blowing
> up an installation's existing users during "make installcheck". In
> particular I believe there w
Tom Lane wrote:
> We've talked before about how the regression tests should be circumspect
> about what role names they create/drop, so as to avoid possibly blowing
> up an installation's existing users during "make installcheck". In
> particular I believe there was consensus that such names shoul
We've talked before about how the regression tests should be circumspect
about what role names they create/drop, so as to avoid possibly blowing
up an installation's existing users during "make installcheck". In
particular I believe there was consensus that such names should begin
with, or at leas
Jeff Davis writes:
> In master, 4 tests fail due to plan changes with blocksize 32K. The
> failures started creeping in around 9.0.
AFAIR, that's been true since the dark ages, not since 9.0.
> I don't see a clean way to make the plans consistent with 8K and 32K
> pages, so I was about to write
In master, 4 tests fail due to plan changes with blocksize 32K. The
failures started creeping in around 9.0.
I don't see a clean way to make the plans consistent with 8K and 32K
pages, so I was about to write this off as "we don't care much".
Then I ran with block size 1KB, and I got what appears
On Tue, Feb 4, 2014 at 12:49 AM, Robert Haas wrote:
> On Fri, Jan 31, 2014 at 5:48 PM, Michael Paquier
> wrote:
>> The part about the planning parameter looks good, thanks. The places
>> used to mention the databases used also makes more sense. Thanks for
>> your input.
>
> OK, committed and back
On Fri, Jan 31, 2014 at 5:48 PM, Michael Paquier
wrote:
> On Sat, Feb 1, 2014 at 12:42 AM, Robert Haas wrote:
>> On Fri, Jan 31, 2014 at 2:28 AM, Michael Paquier
>> wrote:
I took a look at this with a view to committing it but on examination
I'm not sure this is the best way to proceed
On Sat, Feb 1, 2014 at 12:42 AM, Robert Haas wrote:
> On Fri, Jan 31, 2014 at 2:28 AM, Michael Paquier
> wrote:
>>> I took a look at this with a view to committing it but on examination
>>> I'm not sure this is the best way to proceed. The proposed text
>>> documents that the tests should be run
On Fri, Jan 31, 2014 at 2:28 AM, Michael Paquier
wrote:
>> I took a look at this with a view to committing it but on examination
>> I'm not sure this is the best way to proceed. The proposed text
>> documents that the tests should be run in a database called
>> regression, but the larger document
On Fri, Jan 31, 2014 at 6:09 AM, Robert Haas wrote:
> On Thu, Jan 30, 2014 at 3:32 AM, Christian Kruse
> wrote:
>>> For the documentation patch, I propose the attached to avoid future
>>> confusions. Comments? It might make sense to back-patch as well.
>>
>> Compiles, didn't find any typos and I
On Thu, Jan 30, 2014 at 3:32 AM, Christian Kruse
wrote:
>> For the documentation patch, I propose the attached to avoid future
>> confusions. Comments? It might make sense to back-patch as well.
>
> Compiles, didn't find any typos and I think it is comprehensible.
I took a look at this with a vie
Hi,
> For the documentation patch, I propose the attached to avoid future
> confusions. Comments? It might make sense to back-patch as well.
Compiles, didn't find any typos and I think it is comprehensible.
Looks fine for me.
Best regards,
--
Christian Kruse http://www.2ndQuadr
On Fri, Dec 6, 2013 at 12:02 PM, Peter Eisentraut wrote:
> On Thu, 2013-12-05 at 17:12 +0900, Michael Paquier wrote:
>> IMHO, the regression test suite would gain in consistency and
>> portability if we do not refer to data that is database-dependent.
>
> I once did some similar fixes (e3d9dceef62
On Thu, 2013-12-05 at 17:12 +0900, Michael Paquier wrote:
> IMHO, the regression test suite would gain in consistency and
> portability if we do not refer to data that is database-dependent.
I once did some similar fixes (e3d9dceef62e072cf9a433ae6c74a1c5a10d94d3)
but then didn't pursue it any long
> On 2013/12/06, at 3:52, Tom Lane wrote:
>
> Robert Haas writes:
>>> On Thu, Dec 5, 2013 at 9:24 AM, Tom Lane wrote:
>>> Michael Paquier writes:
It happens that the following regression tests are failing if they are
run on a database not named "regression":
>
>>> This does not
Robert Haas writes:
> On Thu, Dec 5, 2013 at 9:24 AM, Tom Lane wrote:
>> Michael Paquier writes:
>>> It happens that the following regression tests are failing if they are
>>> run on a database not named "regression":
>> This does not seem like a bug to me, although maybe we'd better update the
On Thu, Dec 5, 2013 at 9:24 AM, Tom Lane wrote:
> Michael Paquier writes:
>> It happens that the following regression tests are failing if they are
>> run on a database not named "regression":
>
> This does not seem like a bug to me, although maybe we'd better update the
> documentation to specif
Michael Paquier writes:
> It happens that the following regression tests are failing if they are
> run on a database not named "regression":
This does not seem like a bug to me, although maybe we'd better update the
documentation to specify that you need to use a DB named regression.
On Thu, Dec 5, 2013 at 5:12 PM, Michael Paquier
wrote:
> Those tests are failing because some relations of information_schemas
> contain information that are database-dependent.
I forgot to mention that it is our QE team at VMware that reported me
a portion of this failure, and I just had to dig a
Hi all,
It happens that the following regression tests are failing if they are
run on a database not named "regression":
- updatable_views
- foreign_data
- sequence
Those tests are failing because some relations of information_schemas
contain information that are database-dependent. Please see the
On Fri, Sep 6, 2013 at 1:34 PM, Jeremy Harris wrote:
>> What's an index-hash operation?
>
> Ones that hit tuplesort_begin_index_hash()
Oh. Well, it looks to me like that function can only get called when
building a hash index. Specifically, according to the comment in
hashbuild(), a hash index
On 06/09/13 15:44, Robert Haas wrote:
On Fri, Sep 6, 2013 at 3:34 AM, Jeremy Harris wrote:
I don't see the regression tests running any index-hash operations.
What am I missing?
What's an index-hash operation?
Ones that hit tuplesort_begin_index_hash()
--
Cheers,
Jeremy
--
Sent vi
On Fri, Sep 6, 2013 at 3:34 AM, Jeremy Harris wrote:
>I don't see the regression tests running any index-hash operations.
> What am I missing?
What's an index-hash operation?
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
Hi,
I don't see the regression tests running any index-hash operations.
What am I missing?
--
Cheers,
Jeremy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Nov 16, 2011 at 07:08:27PM -0500, Tom Lane wrote:
> I wrote:
> > Simon Riggs writes:
> >> We need a function called transactionid_current() so a normal user can
> >> write
>
> >> select virtualtransaction
> >> from pg_locks
> >> where transactionid = transactionid_current()
>
> >> and h
"Kevin Grittner" writes:
> I wrote a little extension to store a few small strings in shared
> memory. It seems to be working fine, and now I would like to write
> some regression tests; but it's not immediately obvious to me how I
> can do that. The approach used by, for example, citext doesn't
I wrote a little extension to store a few small strings in shared
memory. It seems to be working fine, and now I would like to write
some regression tests; but it's not immediately obvious to me how I
can do that. The approach used by, for example, citext doesn't
work, because I don't see how to
I wrote:
> Simon Riggs writes:
>> We need a function called transactionid_current() so a normal user can write
>> select virtualtransaction
>> from pg_locks
>> where transactionid = transactionid_current()
>> and have it "just work".
> That would solve that one specific use-case. The reason I
Simon Riggs writes:
> We need a function called transactionid_current() so a normal user can write
>select virtualtransaction
>from pg_locks
>where transactionid = transactionid_current()
> and have it "just work".
That would solve that one specific use-case. The reason
On Sun, Nov 13, 2011 at 11:16 PM, Tom Lane wrote:
> While investigating bug #6291 I was somewhat surprised to discover
> $SUBJECT. The cause turns out to be this kluge in alter_table.sql:
>
> select virtualtransaction
> from pg_locks
> where transactionid = txid_current()::in
On Sun, Nov 13, 2011 at 6:16 PM, Tom Lane wrote:
> While investigating bug #6291 I was somewhat surprised to discover
> $SUBJECT. The cause turns out to be this kluge in alter_table.sql:
>
> select virtualtransaction
> from pg_locks
> where transactionid = txid_current()::int
While investigating bug #6291 I was somewhat surprised to discover
$SUBJECT. The cause turns out to be this kluge in alter_table.sql:
select virtualtransaction
from pg_locks
where transactionid = txid_current()::integer
which of course starts to fail with "integer out of
Tom Lane writes:
> Just make two pg_proc entries that are pointing at two C functions.
> The C functions can call a common subroutine after extracting their
> arguments.
Mmmm, ok, will adapt the idea to the current code, where the extracting
is mingled into the processing. Thanks for the idea, th
Dimitri Fontaine writes:
> The pg_execute_from_file() function is designed to work with either a
> filename as its sole argument, or the filename and a VARIADIC text list
> of arguments containing placeholder names and values. It works fine with
> two entries in pg_proc using the same backend func
Hi,
Trying to fix a regression test problem I've left for better days while
developping the extensions, some help is needed.
The pg_execute_from_file() function is designed to work with either a
filename as its sole argument, or the filename and a VARIADIC text list
of arguments containing placeh
On 08/12/2010 10:22 AM, Tom Lane wrote:
Peter Eisentraut writes:
On ons, 2010-08-11 at 16:17 -0400, Tom Lane wrote:
We should have the buildfarm configuration such that any one run uses
the same port number for both installed and uninstalled regression
tests.
I'm getting lost here what the
Peter Eisentraut writes:
> On ons, 2010-08-11 at 16:17 -0400, Tom Lane wrote:
>> We should have the buildfarm configuration such that any one run uses
>> the same port number for both installed and uninstalled regression
>> tests.
> I'm getting lost here what the actual requirements are. The abo
On 08/12/2010 08:43 AM, Peter Eisentraut wrote:
On ons, 2010-08-11 at 15:06 -0400, Andrew Dunstan wrote:
You original email said:
For some historic reasons, I have my local scripts set up so
that they build development instances using the hardcoded port
65432.
I th
On ons, 2010-08-11 at 15:06 -0400, Andrew Dunstan wrote:
> You original email said:
>
> For some historic reasons, I have my local scripts set up so
> that they build development instances using the hardcoded port
> 65432.
>
> I think my response would be "Don't do that".
On ons, 2010-08-11 at 16:17 -0400, Tom Lane wrote:
> We should have the buildfarm configuration such that any one run uses
> the same port number for both installed and uninstalled regression
> tests.
I'm getting lost here what the actual requirements are. The above is
obviously not going to work
On Wed, Aug 11, 2010 at 5:16 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 08/11/2010 04:47 PM, Tom Lane wrote:
>>> I prefer the change-the-default approach mainly because it wouldn't
>>> require any documentation,
>
>> Yeah. The other advantage is that we would not need to wait until we had
Andrew Dunstan writes:
> On 08/11/2010 04:47 PM, Tom Lane wrote:
>> I prefer the change-the-default approach mainly because it wouldn't
>> require any documentation,
> Yeah. The other advantage is that we would not need to wait until we had
> got everyone to update their versions of the buildfar
On 08/11/2010 04:47 PM, Tom Lane wrote:
Andrew Dunstan writes:
Another way would be to have pg_regress honour an environment var like
PG_REGRESS_PORT, which the buildfarm script could use.
Yeah, that would work too. (Is it portable to Windows, though?)
Should be
I prefer the change-the-
Andrew Dunstan writes:
> Another way would be to have pg_regress honour an environment var like
> PG_REGRESS_PORT, which the buildfarm script could use.
Yeah, that would work too. (Is it portable to Windows, though?)
I prefer the change-the-default approach mainly because it wouldn't
require a
On 08/11/2010 04:17 PM, Tom Lane wrote:
We should have the
buildfarm configuration such that any one run uses the same port number
for both installed and uninstalled regression tests. If Peter is dead
set on not changing pg_regress's default, then changing the makefiles to
enable use of the --
Andrew Dunstan writes:
> You original email said:
> For some historic reasons, I have my local scripts set up so that
> they build development instances using the hardcoded port 65432.
> I think my response would be "Don't do that".
Yeah ... or at least use a different port per branch.
On 08/11/2010 02:12 PM, Peter Eisentraut wrote:
Even if you don't, changing this would only mean that you
couldn't safely run "make check" concurrently in multiple branches.
That's exactly the point. The original discussion is here:
http://archives.postgresql.org/message-id/491d9935.9010...
On ons, 2010-08-11 at 11:47 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On ons, 2010-08-11 at 10:15 -0400, Tom Lane wrote:
> >> How about just this:
> >>port = 0xC000 | (DEF_PGPORT & 0x3FFF);
>
> > The version number was put in there intentionally, for developers who
> > work on mul
On ons, 2010-08-11 at 11:53 -0400, Andrew Dunstan wrote:
> > The version number was put in there intentionally, for developers
> who
> > work on multiple branches at once. That's the whole reason this
> code
> > exists. Please don't remove it.
> >
>
> Do they run "make check" by hand simultaneou
"Kevin Grittner" writes:
> Peter Eisentraut wrote:
>> Why not just compare pg_backend_pid() with postmaster.pid?
> See the prior discussion in the archives. We started with that and
> found problems, to which Tom suggested a random number as the best
> solution.
I think Peter's idea is a bit
On ons, 2010-08-11 at 11:48 -0400, Tom Lane wrote:
> How's that help? pg_backend_pid isn't going to return the
> postmaster's
> PID ... maybe we could add a new function that does return the
> postmaster's PID, though.
Hmm, is there a portable way to find the parent PID of some other
process, giv
On 08/11/2010 11:42 AM, Peter Eisentraut wrote:
On ons, 2010-08-11 at 10:15 -0400, Tom Lane wrote:
One of us is missing something. I didn't say to run the checks using
the
configured port. I had in mind something like:
port = 0xC000 | ((PG_VERSION_NUM + DEF_PGPORT)& 0x3FFF);
Oh, I s
Peter Eisentraut wrote:
> On ons, 2010-08-11 at 09:55 -0400, Tom Lane wrote:
>> BTW, I don't know why anyone would think that "a random number"
>> would offer any advantage here. I'd use the postmaster PID,
>> which is guaranteed to be unique across the space that you're
>> worried about. In fac
Peter Eisentraut writes:
> On ons, 2010-08-11 at 10:15 -0400, Tom Lane wrote:
>> How about just this:
>> port = 0xC000 | (DEF_PGPORT & 0x3FFF);
> The version number was put in there intentionally, for developers who
> work on multiple branches at once. That's the whole reason this code
> ex
Peter Eisentraut writes:
> On ons, 2010-08-11 at 09:55 -0400, Tom Lane wrote:
>> BTW, I don't know why anyone would think that "a random number" would
>> offer any advantage here. I'd use the postmaster PID, which is
>> guaranteed to be unique across the space that you're worried about.
>> In fac
On ons, 2010-08-11 at 09:55 -0400, Tom Lane wrote:
> BTW, I don't know why anyone would think that "a random number" would
> offer any advantage here. I'd use the postmaster PID, which is
> guaranteed to be unique across the space that you're worried about.
> In fact, you could implement this off
On ons, 2010-08-11 at 10:15 -0400, Tom Lane wrote:
> > One of us is missing something. I didn't say to run the checks using
> the
> > configured port. I had in mind something like:
>
> > port = 0xC000 | ((PG_VERSION_NUM + DEF_PGPORT) & 0x3FFF);
>
> Oh, I see, modify the DEF_PGPORT don't ju
On 08/11/2010 10:23 AM, Robert Haas wrote:
Or we could do something like
port = 0xC000 ^ (DEF_PGPORT& 0x7FFF);
which is absolutely guaranteed not to conflict with DEF_PGPORT, at the
cost of possibly shifting into the 32K-48K port number range if you
had set DEF_PGPORT above 48K.
I li
Robert Haas writes:
> On Wed, Aug 11, 2010 at 10:15 AM, Tom Lane wrote:
>> Or we could do something like
>>
>> port = 0xC000 ^ (DEF_PGPORT & 0x7FFF);
>>
>> which is absolutely guaranteed not to conflict with DEF_PGPORT, at the
>> cost of possibly shifting into the 32K-48K port number range
Vik Reykja writes:
> We just put in the possibility to name the client connections. Would it be
> interesting to be able to name the server installation itself?
Wouldn't do anything for this problem --- it would just introduce
something else the buildfarm would have to worry about uniqueness of.
On Wed, Aug 11, 2010 at 10:15 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 08/11/2010 09:43 AM, Tom Lane wrote:
>>> Andrew Dunstan writes:
Why not just add the configured port (DEF_PGPORT) into the calculation
of the port to run on?
>
>>> No, that would be just about the worst po
Andrew Dunstan writes:
> On 08/11/2010 09:43 AM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> Why not just add the configured port (DEF_PGPORT) into the calculation
>>> of the port to run on?
>> No, that would be just about the worst possible choice. It'd be
>> guaranteed to fail in the standa
"Kevin Grittner" writes:
> Tom Lane wrote:
>> BTW, I don't know why anyone would think that "a random number"
>> would offer any advantage here. I'd use the postmaster PID, which
>> is guaranteed to be unique across the space that you're worried
>> about.
> Well, in the post I cited, it was yo
Tom Lane wrote:
> BTW, I don't know why anyone would think that "a random number"
> would offer any advantage here. I'd use the postmaster PID, which
> is guaranteed to be unique across the space that you're worried
> about.
Well, in the post I cited, it was you who argued that the PID was a
On 08/11/2010 09:43 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 08/11/2010 12:42 AM, Tom Lane wrote:
... However, it does seem like we ought to be able to
do something about two buildfarm critters defaulting to the same choice
of port number.
Why not just add the configured port (DEF_PGP
"Kevin Grittner" writes:
> Tom Lane wrote:
>> A look at the code shows that it is merely trying to run psql, and
>> if psql reports that it can connect to the specified port, then
>> pg_regress thinks the postmaster started OK. Of course, psql was
>> really reporting that it could connect to the
Tom Lane wrote:
> A look at the code shows that it is merely trying to run psql, and
> if psql reports that it can connect to the specified port, then
> pg_regress thinks the postmaster started OK. Of course, psql was
> really reporting that it could connect to the other instance's
> postmaster
Andrew Dunstan writes:
> On 08/11/2010 12:42 AM, Tom Lane wrote:
>> ... However, it does seem like we ought to be able to
>> do something about two buildfarm critters defaulting to the same choice
>> of port number.
> Why not just add the configured port (DEF_PGPORT) into the calculation
> of t
On 08/11/2010 12:42 AM, Tom Lane wrote:
There's an interesting buildfarm failure here:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecat&dt=2010-08-10%2023:46:10
It appears to me that this was caused by the concurrent run of another
buildfarm animal on the same physical machine, na
On Wed, Aug 11, 2010 at 06:42, Tom Lane wrote:
> I am not sure if there's anything very good we can do about the
> problem of pg_regress misidentifying the postmaster it's managed to
> connect to. A real solution would probably be much more trouble than
> it's worth, anyway. However, it does se
There's an interesting buildfarm failure here:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecat&dt=2010-08-10%2023:46:10
It appears to me that this was caused by the concurrent run of another
buildfarm animal on the same physical machine, namely:
http://buildfarm.postgresql.org/cgi-bi
Correct, that fixes the problem. I've verified it on my machine, and
committed the patch.
//Magnus
On Wed, Sep 12, 2007 at 04:32:57PM +0400, Teodor Sigaev wrote:
> Do you mean something like this:
> ./src/tools/msvc/Install.pm
> *** ./src/tools/msvc/Install.pm.origWed Sep 12 16:30:25 2007
> -
Do you mean something like this:
./src/tools/msvc/Install.pm
*** ./src/tools/msvc/Install.pm.origWed Sep 12 16:30:25 2007
--- ./src/tools/msvc/Install.pm Wed Sep 12 16:31:29 2007
***
*** 66,71
--- 66,72
GenerateTimezoneFiles($target,$conf);
GenerateTsearchFile
Teodor Sigaev wrote:
All windows boxes are failed on tsdicts test:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodon&dt=2007-09-12%2007:00:00
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylark&dt=2007-09-12%2003:00:01
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=baiji&
All windows boxes are failed on tsdicts test:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodon&dt=2007-09-12%2007:00:00
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylark&dt=2007-09-12%2003:00:01
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=baiji&dt=2007-09-11%2022:00:01
wit
On Wednesday 04 May 2005 03:20, Christopher Kings-Lynne wrote:
> > Quite, but in the meantime, a good benchmark should stress the system
> > enough to cause crashes, lockups or at least incorrect results if a
> > bug is introduced in the shared memory or semaphore code, and will
> > definitely reve
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Quite, but in the meantime, a good benchmark should stress the system
>> enough to cause crashes, lockups or at least incorrect results if a
>> bug is introduced in the shared memory or semaphore code, and will
>> definitely reveal any slowdown
Quite, but in the meantime, a good benchmark should stress the system
enough to cause crashes, lockups or at least incorrect results if a
bug is introduced in the shared memory or semaphore code, and will
definitely reveal any slowdowns introduced by new code, so my question
is: where can I find a
Neil Conway <[EMAIL PROTECTED]> writes:
> Dag-Erling Smørgrav wrote:
> > It doesn't stress the system anywhere near enough to reveal bugs in,
> > say, the shared memory or semaphore code.
> I agree -- I think we definitely need more tests for the concurrent
> behavior of the system.
Quite, but in
On Wed, 2005-05-04 at 10:56 +1000, Neil Conway wrote:
> Dag-Erling SmÃrgrav wrote:
> > It doesn't stress the system anywhere near enough to reveal bugs in,
> > say, the shared memory or semaphore code.
>
> I agree -- I think we definitely need more tests for the concurrent
> behavior of the syste
Dag-Erling Smørgrav wrote:
It doesn't stress the system anywhere near enough to reveal bugs in,
say, the shared memory or semaphore code.
I agree -- I think we definitely need more tests for the concurrent
behavior of the system.
-Neil
---(end of broadcast)
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> The whole point of make check is to check correctness, not
> performance.
I understand that.
> It has concurrent loading as well.
It doesn't stress the system anywhere near enough to reveal bugs in,
say, the shared memory or semaphore code.
1 - 100 of 115 matches
Mail list logo
