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
36 matches
Mail list logo
