On Sun, Jun 03, 2007 at 11:29:33PM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Given this, I propose we simply #ifdef out the SO_REUSEADDR on win32.
Anybody see a problem with this?
(A fairly good reference to read up on the options is at
On Sun, Jun 03, 2007 at 10:44:13PM -0400, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
Given this, I propose we simply #ifdef out the SO_REUSEADDR on win32.
Anybody see a problem with this?
Is that true even if the backend crashes?
It would take a
Given this, I propose we simply #ifdef out the SO_REUSEADDR on
win32.
I agree, that this is what we should do.
(A fairly good reference to read up on the options is at
http://msdn2.microsoft.com/en-us/library/ms740621.aspx
Hmm ... if accurate, that page says in words barely
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
+sprintf(mutexName,postgresql.interlock.%i, portNumber);
That won't do; it should be legal for two postmasters to listen on
different IP addresses using the same port number. So you need to
include some representation of
Magnus Hagander wrote:
However, if I just *skip* setting SO_REUSEADDR completely, things seem
to work the way we want it. I cannot start more than one postmaster on
the same addr/port. If I start a psql, then terminate postmaster, I can
restart a new postmaster right away.
Given this, I
Andrew Dunstan [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
Given this, I propose we simply #ifdef out the SO_REUSEADDR on win32.
Anybody see a problem with this?
Is that true even if the backend crashes?
It would take a postmaster crash to make this an issue, and those are
pretty
Magnus Hagander [EMAIL PROTECTED] writes:
Given this, I propose we simply #ifdef out the SO_REUSEADDR on win32.
Anybody see a problem with this?
(A fairly good reference to read up on the options is at
http://msdn2.microsoft.com/en-us/library/ms740621.aspx
Hmm ... if accurate, that page says
On Thu, May 17, 2007 at 07:51:34PM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Are we going to apply this?
Not in the form submitted so far, but I trust Magnus is working on
fixing it.
I am. Most likely won't have time to look at it properly until after pgcon,
though.
Are we going to apply this? I would also like to see a comment added on
why we use SO_REUSEADDR.
---
Magnus Hagander wrote:
On Mon, May 14, 2007 at 09:34:05AM -0400, Andrew Dunstan wrote:
Magnus Hagander wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Are we going to apply this?
Not in the form submitted so far, but I trust Magnus is working on
fixing it.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your
Andrew Dunstan wrote:
Dave Page wrote:
1) There appears to be no way to specify the default port number in the
MSVC build. The buildfarm passes it to configure for regular builds,
which obviously isn't run in VC++ mode, thus leaving the build on 5432.
I have committed fixes to
Andrew Dunstan wrote:
Not to my knowledge, but I have no method of testing what's going on,
and I hate guessing like this - in fact this is what has worried me all
along about supporting MSVC builds - we always said we didn't want to
have to have 2 build environments, but now we have two and
Tom Lane wrote:
So I now state fairly confidently that baiji is failing to overwrite
*any* of the installation tree, /share and /bin both, and instead is
testing an installation dating from sometime between May 1 and May 11.
Close. There was an Msys build from the 9th running on port 5432.
Close. There was an Msys build from the 9th running on port 5432.
2) VC++ and Msys builds will both happily start on the same
port at the same time. The first one to start listens on 5432
until it shuts down, at which point the second server takes
over seamlessly! It doesn't matter which
Zeugswetter Andreas ADI SD wrote:
Close. There was an Msys build from the 9th running on port 5432.
2) VC++ and Msys builds will both happily start on the same
port at the same time. The first one to start listens on 5432
until it shuts down, at which point the second server takes
over
Dave Page wrote:
Tom Lane wrote:
So I now state fairly confidently that baiji is failing to overwrite
*any* of the installation tree, /share and /bin both, and instead is
testing an installation dating from sometime between May 1 and May 11.
Close. There was an Msys build from the
Dave Page [EMAIL PROTECTED] writes:
2) VC++ and Msys builds will both happily start on the same port at the
same time. The first one to start listens on 5432 until it shuts down,
at which point the second server takes over seamlessly!
Uh ... so the lock-file stuff is completely broken on
Andrew Dunstan wrote:
I'll look at the port mess.
Are you running 2 buildfarm members on the same machine? If so, you
should look at using the multi-root factility which is explicitly
designed to avoid clashes of this sort.
Yes, I've got VC++ and Mingw/Msys animals on each of two
I wrote:
Uh ... so the lock-file stuff is completely broken on Windows?
Not so much broken as commented out ... on looking at the code, it's
blindingly obvious that we don't even try to create a socket lock file
if not HAVE_UNIX_SOCKETS. Sigh.
There is a related risk even on Unix machines: two
On Mon, May 14, 2007 at 08:50:54AM -0400, Tom Lane wrote:
I wrote:
Uh ... so the lock-file stuff is completely broken on Windows?
Not so much broken as commented out ... on looking at the code, it's
blindingly obvious that we don't even try to create a socket lock file
if not
Magnus Hagander [EMAIL PROTECTED] writes:
If all we want to do is add a check that prevents two servers to start on
the same port, we could do that trivially in a win32 specific way (since
we'll never have unix sockets there). Just create an object in the global
namespace named
* Tom Lane ([EMAIL PROTECTED]) wrote:
There is a related risk even on Unix machines: two postmasters can be
started on the same port number if they have different settings of
unix_socket_directory, and then it's indeterminate which one you will
contact if you connect to the TCP port. I seem
Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
There is a related risk even on Unix machines: two postmasters can be
started on the same port number if they have different settings of
unix_socket_directory, and then it's indeterminate which one you will
contact if you connect to
Tom Lane [EMAIL PROTECTED] writes:
I wrote:
Uh ... so the lock-file stuff is completely broken on Windows?
Not so much broken as commented out ... on looking at the code, it's
blindingly obvious that we don't even try to create a socket lock file
if not HAVE_UNIX_SOCKETS. Sigh.
Isn't the
On Mon, May 14, 2007 at 09:02:10AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
If all we want to do is add a check that prevents two servers to start on
the same port, we could do that trivially in a win32 specific way (since
we'll never have unix sockets there). Just
Magnus Hagander wrote:
On Mon, May 14, 2007 at 09:02:10AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
If all we want to do is add a check that prevents two servers to start on
the same port, we could do that trivially in a win32 specific way (since
we'll never
Dave Page [EMAIL PROTECTED] writes:
Stephen Frost wrote:
I'm curious as to which Unix systems allow multiple processes to listen
on the same port at the same time.. On Linux, and I thought on most,
you get an EADDRINUSE on the listen() call (which the postmaster should
pick up on and bomb
Tom Lane wrote:
Setting the SO_REUSEADDR option allows the local socket address to be
reused in subsequent calls to bind(). This permits multiple
SOCK_STREAM sockets to be bound to the same local address, as long as
all existing sockets with the desired local address are
Tom Lane wrote:
Windows seems to treat SO_REUSEADDR in the same
way as SO_REUSEPORT which just seems wrong.
Well, Microsoft getting standards wrong is no surprise. So what do we
want to do about it?
Microsoft did lift that code from BSD many moons ago, so it might be
worth checking if the
Andrew Dunstan wrote:
Magnus Hagander wrote:
On Mon, May 14, 2007 at 09:02:10AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
If all we want to do is add a check that prevents two servers to start on
the same port, we could do that trivially in a win32
Andrew Dunstan [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
If all we want to do is add a check that prevents two servers to start on
the same port, we could do that trivially in a win32 specific way (since
we'll never have unix sockets there). Just create an object in the global
On Mon, May 14, 2007 at 09:49:47AM -0400, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
If all we want to do is add a check that prevents two servers to start on
the same port, we could do that trivially in a win32 specific way (since
we'll never have
On Mon, May 14, 2007 at 09:34:05AM -0400, Andrew Dunstan wrote:
Magnus Hagander wrote:
On Mon, May 14, 2007 at 09:02:10AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
If all we want to do is add a check that prevents two servers to start on
the same port, we
Tom Lane [EMAIL PROTECTED] writes:
What happens if we just #ifndef WIN32 the setsockopt(SO_REUSEADDR)
call? I believe the reason that's in there is that some platforms will
reject bind() to a previously-used address for a TCP timeout delay after
a previous postmaster quit, but if that
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
What happens if we just #ifndef WIN32 the setsockopt(SO_REUSEADDR)
call? I believe the reason that's in there is that some platforms will
reject bind() to a previously-used address for a TCP timeout delay after
a
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Tom Lane [EMAIL PROTECTED] [070514 10:24]:
This is not a behavior required by the TCP spec AFAICS. Also, in a
quick test neither Linux nor HPUX appear to need SO_REUSEADDR --- on
both, I can restart the postmaster immediately without it.
Did you
* Tom Lane [EMAIL PROTECTED] [070514 10:24]:
This is not a behavior required by the TCP spec AFAICS. Also, in a
quick test neither Linux nor HPUX appear to need SO_REUSEADDR --- on
both, I can restart the postmaster immediately without it.
Did you have an active connection before
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
What happens if we just #ifndef WIN32 the setsockopt(SO_REUSEADDR)
call? I believe the reason that's in there is that some platforms will
reject bind() to a previously-used address
Magnus Hagander [EMAIL PROTECTED] writes:
+ sprintf(mutexName,postgresql.interlock.%i, portNumber);
That won't do; it should be legal for two postmasters to listen on
different IP addresses using the same port number. So you need to
include some representation of the IP address
Tom Lane [EMAIL PROTECTED] writes:
Um, you're right, I hadn't done the test properly. If I have an open
psql session across TCP and do pg_ctl stop -m fast, then I can't
start a new postmaster until the socket goes out of CLOSE_WAIT state.
Which, if I just leave the psql session sit there,
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Um, you're right, I hadn't done the test properly. If I have an open
psql session across TCP and do pg_ctl stop -m fast, then I can't
start a new postmaster until the socket goes out of CLOSE_WAIT state.
Which, if I
Dave Page wrote:
Where can I find out about multi-root? I can't see anything in the
config file, or in PGBuildFarm-HOWTO.txt
It's a hack I want to get rid of. It's a command-line option:
--multiroot = allow several members to use same build root
Of course, at least
On 2007-05-14, Tom Lane [EMAIL PROTECTED] wrote:
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Tom Lane [EMAIL PROTECTED] [070514 10:24]:
This is not a behavior required by the TCP spec AFAICS. Also, in a
quick test neither Linux nor HPUX appear to need SO_REUSEADDR --- on
both, I can restart
Andrew Dunstan wrote:
Dave Page wrote:
Where can I find out about multi-root? I can't see anything in the
config file, or in PGBuildFarm-HOWTO.txt
It's a hack I want to get rid of. It's a command-line option:
--multiroot = allow several members to use same build root
Dave Page wrote:
1) There appears to be no way to specify the default port number in the
MSVC build. The buildfarm passes it to configure for regular builds,
which obviously isn't run in VC++ mode, thus leaving the build on 5432.
I have committed fixes to both pgsql and buildfarm that
Andrew Dunstan wrote:
Tom Lane wrote:
The last two runs on baiji have failed at the installcheck stage,
with symptoms that look a heck of a lot like the most recent system
catalog changes haven't taken effect (eg, it doesn't seem to know
about pg_type.typarray). Given that the previous check
Magnus Hagander wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
The last two runs on baiji have failed at the installcheck stage,
with symptoms that look a heck of a lot like the most recent system
catalog changes haven't taken effect (eg, it doesn't seem to know
about pg_type.typarray). Given
Andrew Dunstan wrote:
Magnus Hagander wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
The last two runs on baiji have failed at the installcheck stage,
with symptoms that look a heck of a lot like the most recent system
catalog changes haven't taken effect (eg, it doesn't seem to know
about
Magnus Hagander wrote:
My point was that I can't even investigate how MSVC is working
at all.
So what is it you're looking for, specifically, to help with that?
As a very bare minimum, we need to change the installation procedure to
log its destination.
Unless that has somehow got screwed
Andrew Dunstan wrote:
Magnus Hagander wrote:
My point was that I can't even investigate how MSVC is working
at all.
So what is it you're looking for, specifically, to help with that?
As a very bare minimum, we need to change the installation procedure to
log its destination.
Unless
Magnus Hagander wrote:
! print Installing for $conf in $target\n;
Looks like a good place to start, sure.
cheers
andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Andrew Dunstan wrote:
Magnus Hagander wrote:
! print Installing for $conf in $target\n;
Looks like a good place to start, sure.
Ok. Applied.
//Magnus
---(end of broadcast)---
TIP 5: don't forget to increase your free space
Andrew Dunstan [EMAIL PROTECTED] writes:
Unless that has somehow got screwed up I can't see how Tom's theory of a
possibly left over .bki file can stand up.
Well, I tried inserting a .bki file from April 30 into a HEAD
installation, and that made it dump core during bootstrap, so that
offhand
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Unless that has somehow got screwed up I can't see how Tom's theory of a
possibly left over .bki file can stand up.
Well, I tried inserting a .bki file from April 30 into a HEAD
installation, and that made it dump core during
The last two runs on baiji have failed at the installcheck stage,
with symptoms that look a heck of a lot like the most recent system
catalog changes haven't taken effect (eg, it doesn't seem to know
about pg_type.typarray). Given that the previous check step
passed, the most likely explanation
Tom Lane wrote:
The last two runs on baiji have failed at the installcheck stage,
with symptoms that look a heck of a lot like the most recent system
catalog changes haven't taken effect (eg, it doesn't seem to know
about pg_type.typarray). Given that the previous check step
passed, the most
56 matches
Mail list logo
