Re: [HACKERS] regression tests fails

2016-11-21 Thread Tom Lane
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

Re: [HACKERS] regression tests fails

2016-11-20 Thread Pavel Stehule
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(*), >> >

Re: [HACKERS] regression tests fails

2016-11-20 Thread 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

Re: [HACKERS] regression tests fails

2016-11-20 Thread 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 > ~ 'INSERT' > GROUP BY 1

Re: [HACKERS] regression tests fails

2016-11-20 Thread Pavel Stehule
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 >

[HACKERS] regression tests fails

2016-11-15 Thread 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 regression test queries== test ddl

Re: [HACKERS] Regression tests vs existing users in an installation

2016-07-21 Thread Robert Haas
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

Re: [HACKERS] Regression tests vs existing users in an installation

2016-07-21 Thread Robert Haas
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

Re: [HACKERS] Regression tests vs existing users in an installation

2016-07-18 Thread Tom Lane
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

Re: [HACKERS] Regression tests vs existing users in an installation

2016-07-18 Thread Peter Eisentraut
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

Re: [HACKERS] Regression tests vs existing users in an installation

2016-07-18 Thread Tom Lane
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

Re: [HACKERS] Regression tests vs existing users in an installation

2016-07-17 Thread Michael Paquier
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

Re: [HACKERS] Regression tests vs existing users in an installation

2016-07-17 Thread Robert Haas
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 >

Re: [HACKERS] Regression tests vs existing users in an installation

2016-07-17 Thread Tom Lane
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

Re: [HACKERS] Regression tests vs existing users in an installation

2016-07-16 Thread Tom Lane
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 >>

Re: [HACKERS] Regression tests vs existing users in an installation

2016-07-16 Thread Tom Lane
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

Re: [HACKERS] Regression tests vs existing users in an installation

2016-07-16 Thread Stephen Frost
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

Re: [HACKERS] Regression tests vs existing users in an installation

2016-07-16 Thread Greg Stark
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

Re: [HACKERS] Regression tests vs existing users in an installation

2016-07-16 Thread Michael Paquier
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 >

Re: [HACKERS] Regression tests vs existing users in an installation

2016-07-15 Thread Alvaro Herrera
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

[HACKERS] Regression tests vs existing users in an installation

2016-07-15 Thread Tom Lane
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

[HACKERS] regression tests fail for different block sizes

2014-05-14 Thread Jeff Davis
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

Re: [HACKERS] regression tests fail for different block sizes

2014-05-14 Thread Tom Lane
Jeff Davis pg...@j-davis.com 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

Re: [HACKERS] Regression tests failing if not launched on db regression

2014-02-03 Thread Robert Haas
On Fri, Jan 31, 2014 at 5:48 PM, Michael Paquier michael.paqu...@gmail.com wrote: On Sat, Feb 1, 2014 at 12:42 AM, Robert Haas robertmh...@gmail.com wrote: On Fri, Jan 31, 2014 at 2:28 AM, Michael Paquier michael.paqu...@gmail.com wrote: I took a look at this with a view to committing it but

Re: [HACKERS] Regression tests failing if not launched on db regression

2014-02-03 Thread Michael Paquier
On Tue, Feb 4, 2014 at 12:49 AM, Robert Haas robertmh...@gmail.com wrote: On Fri, Jan 31, 2014 at 5:48 PM, Michael Paquier michael.paqu...@gmail.com wrote: The part about the planning parameter looks good, thanks. The places used to mention the databases used also makes more sense. Thanks for

Re: [HACKERS] Regression tests failing if not launched on db regression

2014-01-31 Thread Robert Haas
On Fri, Jan 31, 2014 at 2:28 AM, Michael Paquier michael.paqu...@gmail.com 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

Re: [HACKERS] Regression tests failing if not launched on db regression

2014-01-31 Thread Michael Paquier
On Sat, Feb 1, 2014 at 12:42 AM, Robert Haas robertmh...@gmail.com wrote: On Fri, Jan 31, 2014 at 2:28 AM, Michael Paquier michael.paqu...@gmail.com 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

Re: [HACKERS] Regression tests failing if not launched on db regression

2014-01-30 Thread Christian Kruse
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

Re: [HACKERS] Regression tests failing if not launched on db regression

2014-01-30 Thread Robert Haas
On Thu, Jan 30, 2014 at 3:32 AM, Christian Kruse christ...@2ndquadrant.com 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

Re: [HACKERS] Regression tests failing if not launched on db regression

2014-01-30 Thread Michael Paquier
On Fri, Jan 31, 2014 at 6:09 AM, Robert Haas robertmh...@gmail.com wrote: On Thu, Jan 30, 2014 at 3:32 AM, Christian Kruse christ...@2ndquadrant.com wrote: For the documentation patch, I propose the attached to avoid future confusions. Comments? It might make sense to back-patch as well.

[HACKERS] Regression tests failing if not launched on db regression

2013-12-05 Thread Michael Paquier
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

Re: [HACKERS] Regression tests failing if not launched on db regression

2013-12-05 Thread Michael Paquier
On Thu, Dec 5, 2013 at 5:12 PM, Michael Paquier michael.paqu...@gmail.com 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,

Re: [HACKERS] Regression tests failing if not launched on db regression

2013-12-05 Thread Tom Lane
Michael Paquier michael.paqu...@gmail.com 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

Re: [HACKERS] Regression tests failing if not launched on db regression

2013-12-05 Thread Robert Haas
On Thu, Dec 5, 2013 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote: Michael Paquier michael.paqu...@gmail.com 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

Re: [HACKERS] Regression tests failing if not launched on db regression

2013-12-05 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Thu, Dec 5, 2013 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote: Michael Paquier michael.paqu...@gmail.com writes: It happens that the following regression tests are failing if they are run on a database not named regression: This does not seem

Re: [HACKERS] Regression tests failing if not launched on db regression

2013-12-05 Thread Michael Paquier
On 2013/12/06, at 3:52, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Thu, Dec 5, 2013 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote: Michael Paquier michael.paqu...@gmail.com writes: It happens that the following regression tests are failing if they

Re: [HACKERS] Regression tests failing if not launched on db regression

2013-12-05 Thread Peter Eisentraut
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

Re: [HACKERS] Regression tests failing if not launched on db regression

2013-12-05 Thread Michael Paquier
On Fri, Dec 6, 2013 at 12:02 PM, Peter Eisentraut pete...@gmx.net 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

[HACKERS] regression tests

2013-09-06 Thread Jeremy Harris
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

Re: [HACKERS] regression tests

2013-09-06 Thread Robert Haas
On Fri, Sep 6, 2013 at 3:34 AM, Jeremy Harris j...@wizmail.org 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

Re: [HACKERS] regression tests

2013-09-06 Thread Jeremy Harris
On 06/09/13 15:44, Robert Haas wrote: On Fri, Sep 6, 2013 at 3:34 AM, Jeremy Harris j...@wizmail.org 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,

Re: [HACKERS] regression tests

2013-09-06 Thread Robert Haas
On Fri, Sep 6, 2013 at 1:34 PM, Jeremy Harris j...@wizmail.org 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(),

Re: [HACKERS] Regression tests fail once XID counter exceeds 2 billion

2012-08-16 Thread Bruce Momjian
On Wed, Nov 16, 2011 at 07:08:27PM -0500, Tom Lane wrote: I wrote: Simon Riggs si...@2ndquadrant.com writes: We need a function called transactionid_current() so a normal user can write select virtualtransaction from pg_locks where transactionid = transactionid_current() and

[HACKERS] Regression tests for preload extension

2012-04-25 Thread Kevin Grittner
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

Re: [HACKERS] Regression tests for preload extension

2012-04-25 Thread Tom Lane
Kevin Grittner kevin.gritt...@wicourts.gov 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

Re: [HACKERS] Regression tests fail once XID counter exceeds 2 billion

2011-11-16 Thread Tom Lane
I wrote: Simon Riggs si...@2ndquadrant.com 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

Re: [HACKERS] Regression tests fail once XID counter exceeds 2 billion

2011-11-15 Thread Simon Riggs
On Sun, Nov 13, 2011 at 11:16 PM, Tom Lane t...@sss.pgh.pa.us 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 =

Re: [HACKERS] Regression tests fail once XID counter exceeds 2 billion

2011-11-15 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com 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

Re: [HACKERS] Regression tests fail once XID counter exceeds 2 billion

2011-11-14 Thread Robert Haas
On Sun, Nov 13, 2011 at 6:16 PM, Tom Lane t...@sss.pgh.pa.us 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 =

[HACKERS] Regression tests fail once XID counter exceeds 2 billion

2011-11-13 Thread Tom Lane
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

[HACKERS] Regression Tests (opr) Sanity

2010-11-25 Thread Dimitri Fontaine
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

Re: [HACKERS] Regression Tests (opr) Sanity

2010-11-25 Thread Tom Lane
Dimitri Fontaine dimi...@2ndquadrant.fr 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

Re: [HACKERS] Regression Tests (opr) Sanity

2010-11-25 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-12 Thread Peter Eisentraut
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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-12 Thread Peter Eisentraut
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. Do you

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-12 Thread Andrew Dunstan
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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-12 Thread Tom Lane
Peter Eisentraut pete...@gmx.net 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.

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-12 Thread Andrew Dunstan
On 08/12/2010 10:22 AM, Tom Lane wrote: Peter Eisentrautpete...@gmx.net 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Vik Reykja
On Wed, Aug 11, 2010 at 06:42, Tom Lane t...@sss.pgh.pa.us 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.

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Andrew Dunstan
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=polecatdt=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,

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Tom Lane
Andrew Dunstan and...@dunslane.net 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Kevin Grittner
Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Tom Lane
Kevin Grittner kevin.gritt...@wicourts.gov writes: Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Andrew Dunstan
On 08/11/2010 09:43 AM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Kevin Grittner
Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Tom Lane
Kevin Grittner kevin.gritt...@wicourts.gov writes: Tom Lane t...@sss.pgh.pa.us 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.

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: On 08/11/2010 09:43 AM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Robert Haas
On Wed, Aug 11, 2010 at 10:15 AM, Tom Lane t...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net writes: On 08/11/2010 09:43 AM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net  writes: Why not just add the configured port (DEF_PGPORT) into the calculation of the port to run on?

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Tom Lane
Vik Reykja vikrey...@gmail.com 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Wed, Aug 11, 2010 at 10:15 AM, Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Andrew Dunstan
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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Peter Eisentraut
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 just use it

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Peter Eisentraut
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 the

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Tom Lane
Peter Eisentraut pete...@gmx.net 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.

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Tom Lane
Peter Eisentraut pete...@gmx.net 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Kevin Grittner
Peter Eisentraut pete...@gmx.net 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.

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Andrew Dunstan
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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Peter Eisentraut
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, given

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Tom Lane
Kevin Grittner kevin.gritt...@wicourts.gov writes: Peter Eisentraut pete...@gmx.net 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Peter Eisentraut
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 simultaneously on

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Peter Eisentraut
On ons, 2010-08-11 at 11:47 -0400, Tom Lane wrote: Peter Eisentraut pete...@gmx.net 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Andrew Dunstan
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:

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Tom Lane
Andrew Dunstan and...@dunslane.net 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Andrew Dunstan
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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Tom Lane
Andrew Dunstan and...@dunslane.net 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Andrew Dunstan
On 08/11/2010 04:47 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Tom Lane
Andrew Dunstan and...@dunslane.net 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

Re: [HACKERS] Regression tests versus the buildfarm environment

2010-08-11 Thread Christopher Browne
On Wed, Aug 11, 2010 at 5:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net 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

[HACKERS] Regression tests versus the buildfarm environment

2010-08-10 Thread Tom Lane
There's an interesting buildfarm failure here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecatdt=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:

[HACKERS] regression tests of dictionaries and Windows

2007-09-12 Thread Teodor Sigaev
All windows boxes are failed on tsdicts test: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2007-09-12%2007:00:00 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylarkdt=2007-09-12%2003:00:01 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=baijidt=2007-09-11%2022:00:01 with

Re: [HACKERS] regression tests of dictionaries and Windows

2007-09-12 Thread Andrew Dunstan
Teodor Sigaev wrote: All windows boxes are failed on tsdicts test: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2007-09-12%2007:00:00 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylarkdt=2007-09-12%2003:00:01

Re: [HACKERS] regression tests of dictionaries and Windows

2007-09-12 Thread Teodor Sigaev
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);

Re: [HACKERS] regression tests of dictionaries and Windows

2007-09-12 Thread Magnus Hagander
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 ---

Re: [HACKERS] Regression tests

2005-05-04 Thread Simon Riggs
On Wed, 2005-05-04 at 10:56 +1000, Neil Conway wrote: Dag-Erling Smrgrav 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.

Re: [HACKERS] Regression tests

2005-05-04 Thread =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=
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 the

Re: [HACKERS] Regression tests

2005-05-04 Thread Christopher Kings-Lynne
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

Re: [HACKERS] Regression tests

2005-05-04 Thread Tom Lane
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 slowdowns

Re: [HACKERS] Regression tests

2005-05-04 Thread Robert Treat
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 reveal any

[HACKERS] Regression tests

2005-05-03 Thread Dag-Erling Smørgrav
Are there any regression tests or unit tests beyond 'make check', or possibly benchmarks which not only measure performance but also verify that the results are correct? I have patches which I want to test under high load from multiple concurrent clients, so 'make check' isn't enough. Google has

Re: [HACKERS] Regression tests

2005-05-03 Thread Christopher Kings-Lynne
Are there any regression tests or unit tests beyond 'make check', or possibly benchmarks which not only measure performance but also verify that the results are correct? I have patches which I want to test under high load from multiple concurrent clients, so 'make check' isn't enough. Google has

  1   2   >