Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Not ignoring errors is one of the staples of PostgreSQL. What you are
> proposing here sounds entirely like a MySQL design plan. Maybe that is
> newbie-friendly in your mind, but I really doubt that. I agree that we
> do not want to force people
Tom Lane wrote:
> > I think we could also error out if we cannot create at least one
> > listen socket for each entry in listen_addresses (instead of at
> > least one overall).
>
> No; that will break cases that don't need to break.
Which cases would that be? If you specify a host name and it doe
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Reading the comments in StreamServerPort, it seems the only problem we
> can't go fatal error everywhere is that on some systems the IPv4 and
> IPv6 sockets fight each other when bind() is called. For the other
> failure modes, it seems that no suc
I wrote:
> The least thing it should do is error out if *no* TCP/IP port could
> be created while listen_addresses is set.
It's doing that now, and that should guard against the most common
problem, namemly the port already being occupied (since all TCP/IP
listen sockets use the same port).
Rea
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
What behavior are you proposing, exactly?
The least thing it should do is error out if *no* TCP/IP port could be
created while listen_addresses is set.
That might be reasonable --- I thin
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What behavior are you proposing, exactly?
> The least thing it should do is error out if *no* TCP/IP port could be
> created while listen_addresses is set.
That might be reasonable --- I think right now we only die if we
couldn't
Tom Lane wrote:
> What behavior are you proposing, exactly?
The least thing it should do is error out if *no* TCP/IP port could be
created while listen_addresses is set.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)--
I wrote:
> Andrew Dunstan wrote:
> > see
> > http://archives.postgresql.org/pgsql-hackers/2004-03/msg00679.php
>
> Well, with once release of field experience behind me I'd like to
> revisit this idea. Who would actually be hurt by generating an error
> here like it used to do?
It seems that the
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> During a recent training session I was reminded about a peculiar
> misbehavior that recent PostgreSQL releases exhibit when the TCP port
> they are trying to bind to is occupied:
> LOG: could not bind IPv4 socket: Address already in use
> HINT: Is
Andrew Dunstan wrote:
> see http://archives.postgresql.org/pgsql-hackers/2004-03/msg00679.php
Well, with once release of field experience behind me I'd like to
revisit this idea. Who would actually be hurt by generating an error
here like it used to do?
--
Peter Eisentraut
http://developer.po
Alvaro Herrera wrote:
> If the TCP socket is used we can still bind to the Unix-domain
> socket, no?
If I configured a TCP/IP socket, what good does a Unix-domain socket do
me?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
On Tue, Jun 28, 2005 at 03:14:29PM +0200, Peter Eisentraut wrote:
> Andrew Dunstan wrote:
> > IIRC, in previous versions any bind failure was fatal, but in 8.0 we
> > decided to be slightly more forgiving and only bail out if we failed
> > to bind at all.
>
> I realize that, but I would like to kn
Peter Eisentraut wrote:
Andrew Dunstan wrote:
IIRC, in previous versions any bind failure was fatal, but in 8.0 we
decided to be slightly more forgiving and only bail out if we failed
to bind at all.
I realize that, but I would like to know where that bright idea came
from in viola
At 2005-06-28 15:14:29 +0200, [EMAIL PROTECTED] wrote:
>
> I recall that it had something to do with IPv6, but I'm not sure.
Under Linux, if you bind to AF_INET6/::0, a subsequent bind to AF_INET/0
will fail, but the IPv4 address is also bound by the first call, and the
program will accept IPv4 co
Andrew Dunstan wrote:
> IIRC, in previous versions any bind failure was fatal, but in 8.0 we
> decided to be slightly more forgiving and only bail out if we failed
> to bind at all.
I realize that, but I would like to know where that bright idea came
from in violation of all other principles of t
Peter Eisentraut said:
> During a recent training session I was reminded about a peculiar
> misbehavior that recent PostgreSQL releases exhibit when the TCP port
> they are trying to bind to is occupied:
>
> LOG: could not bind IPv4 socket: Address already in use
> HINT: Is another postmaster alr
16 matches
Mail list logo
