Tom Lane wrote:
So the postmaster-log message may be the best we can do ...
but I don't think we should drop the connection.
Here's a patch to do that; it appears to work as intended on my Linux
system.
-O
Index: src/backend/libpq/pqcomm.c
Tom Lane wrote:
If the connection gets accepted, I'd expect *something* in the
postmaster logs -- can you check?
I suspect Merlin's complaint has to do with the fact that the *user*
doesn't see any error message. The way you've coded this, setsockopt
failure during startup is treated as
Here's a patch that adds four new GUCs:
tcp_keepalives (defaults to on, controls SO_KEEPALIVE)
tcp_keepalives_idle (controls TCP_KEEPIDLE)
tcp_keepalives_interval (controls TCP_KEEPINTVL)
tcp_keepalives_count (controls TCP_KEEPCNT)
I just tested this on my windows XP machine
Merlin Moncure wrote:
Here's a patch that adds four new GUCs:
tcp_keepalives (defaults to on, controls SO_KEEPALIVE)
tcp_keepalives_idle (controls TCP_KEEPIDLE)
tcp_keepalives_interval (controls TCP_KEEPINTVL)
tcp_keepalives_count (controls TCP_KEEPCNT)
I just tested this on my
Oliver Jowett [EMAIL PROTECTED] writes:
Merlin Moncure wrote:
Even better would be a stronger test to make sure o/s supports this
feature.
Well, the code assumes that if the TCP_* constants are present then they
can be used. It seems a bit stupid if Windows defines them but doesn't
support
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Merlin Moncure wrote:
Even better would be a stronger test to make sure o/s supports this
feature.
Well, the code assumes that if the TCP_* constants are present then they
can be used. It seems a bit stupid if Windows defines them but
Oliver Jowett [EMAIL PROTECTED] writes:
The assumption I'm making is that if the TCP_* values are present at
compile time, then you can make a setsockopt() call and get a sane error
code back if there's no support -- rather than a segfault, or having the
OS spontaneously do weird things to the
Oliver Jowett [EMAIL PROTECTED] writes:
Merlin Moncure wrote:
More
significantly, if you change a tcp parameter from the default, the
server rejects connections without a relevant error message :(.
Could you clarify what you mean by rejects? Does it accept them and
then close the
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
The assumption I'm making is that if the TCP_* values are present at
compile time, then you can make a setsockopt() call and get a sane error
code back if there's no support -- rather than a segfault, or having the
OS spontaneously do
Oliver Jowett [EMAIL PROTECTED] writes:
We could just log (already done inside pq_*, IIRC) and continue, instead
of erroring out. It's just the way it is because I personally prefer
misconfigurations to break loudly, so you have to fix them ;-)
Well, dropping the connection with no message
Tom Lane wrote:
I'm not sure if we can issue a notice that will be seen on the client
side at this point in the startup cycle. I seem to recall the protocol
document advising against sending NOTICEs during the authentication
cycle.
As currently written the setsockopt() calls are done very
Is this the functionality we agreed we wanted?
---
Oliver Jowett wrote:
Bruce Momjian wrote:
Is this patch being worked on?
Here's an updated version. It compiles and appears to work as expected
under Linux (supports
Bruce Momjian wrote:
Is this the functionality we agreed we wanted?
I think it covers Tom's comments on the first version:
- a GUC to turn off SO_KEEPALIVE isn't particularly useful
- don't do redundant get/setsockopt calls on backend startup
-O
---(end of
Bruce Momjian wrote:
Is this patch being worked on?
Here's an updated version. It compiles and appears to work as expected
under Linux (supports TCP_KEEPIDLE etc) and Solaris 9 (no support).
Main changes:
- removed the tcp_keepalives GUC, SO_KEEPALIVE is now always on (as in
current CVS)
-
Oliver Jowett wrote:
Bruce Momjian wrote:
Is this patch being worked on?
I have shelved it for the moment, waiting on any further comments from
Tom before reworking it.
I thought he wanted the patch modified so keepalive could never be
turned off, but that the OS default parameters could
Oliver Jowett [EMAIL PROTECTED] writes:
Here's a patch that adds four new GUCs:
tcp_keepalives (defaults to on, controls SO_KEEPALIVE)
tcp_keepalives_idle (controls TCP_KEEPIDLE)
tcp_keepalives_interval (controls TCP_KEEPINTVL)
tcp_keepalives_count (controls TCP_KEEPCNT)
Do you
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Here's a patch that adds four new GUCs:
tcp_keepalives (defaults to on, controls SO_KEEPALIVE)
tcp_keepalives_idle (controls TCP_KEEPIDLE)
tcp_keepalives_interval (controls TCP_KEEPINTVL)
tcp_keepalives_count (controls
Oliver Jowett wrote:
Here's a patch that adds four new GUCs:
I haven't had a chance to check it builds on other systems or to test
that this handles actual network failures nicely yet.
The patch builds OK on Solaris 9, which doesn't have the required socket
options.
Solaris (and some other
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not convinced that Postgres ought to provide
a way to second-guess the TCP stack ...
Would you be ok with a patch that allowed configuration of the
TCP_KEEPCNT / TCP_KEEPIDLE / TCP_KEEPINTVL socket options on
19 matches
Mail list logo
