Martijn van Oosterhout wrote:
> To support COLLATE PostgreSQL's locale support needs to be upgraded
> and made more flexible. This is not a surprise. Anything that doesn't
> use the new interface isn't affected. I'm a little confused where the
> problem is.
You were proposing to effectively make a
On Thu, Sep 08, 2005 at 07:00:08PM +0200, Peter Eisentraut wrote:
> Martijn van Oosterhout wrote:
> > To support COLLATE PostgreSQL's locale support needs to be upgraded
> > and made more flexible. This is not a surprise. Anything that doesn't
> > use the new interface isn't affected. I'm a little
> 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
Two items the body of the FAQ are numbered 4.20 (the table of
contents correctly has 4.20 and 4.21). This patch fixes that.
--
Michael Fuhr
Index: doc/src/FAQ/FAQ.html
===
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ.html,v
ret
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
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
>
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:
> 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
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
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:
> 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 ver
12 matches
Mail list logo
