Oliver Jowett <[EMAIL PROTECTED]> writes:
> 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.
Applied along with some other marginal c
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 trea
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 ver
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:
> 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 spontaneou
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 th
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 t
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 Windo
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
>
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 th
> 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 r
Patch applied. Thanks.
---
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 TCP_KEEPIDLE etc
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 broadcast)
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 (sup
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)
- {ge
Bruce Momjian writes:
> Oliver Jowett wrote:
>> 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 be changed.
I wanted it
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
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.
-O
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Is this patch being worked on?
---
Oliver Jowett wrote:
> Tom Lane wrote:
> > Oliver Jowett <[EMAIL PROTECTED]> writes:
> >
> >>Here's a patch that adds four new GUCs:
> >
> >
> >> tcp_keepalives (defaults to on, control
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 TCP_KEEPCN
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 yo
Bruce Momjian writes:
> I am not very excited about adding four more GUC variables, and I am
> thinking we could just have it use the OS defaults and see if we need
> more later, so that would add only one GUC.
Huh? "Use the OS defaults" is where we are now.
I'm unconvinced of the value of allo
Bruce Momjian wrote:
> Where are we on this? I do think it solves a problem that some are
> having, and it seems it would detect a disconnected client and abort a
> long running query.
I haven't had a chance to do any work to support the Solaris stuff, but
otherwise I'm just waiting on review.
N
Where are we on this? I do think it solves a problem that some are
having, and it seems it would detect a disconnected client and abort a
long running query.
I am not very excited about adding four more GUC variables, and I am
thinking we could just have it use the OS defaults and see if we need
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 othe
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 soc
27 matches
Mail list logo
