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
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
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
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
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
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)
-
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_KEEPCNT
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
Hans-Jürgen Schönig wrote:
If the JDBC driver prefers different behaviour (maybe for prepared
statements) we should discuss further options for RESET.
Now there is: RESET CONNECTION (cleaning entire connection), RESET ALL
(cleaning GUCS only) and RESET some_guc.
Maybe we want RESET LISTENER,
(cc'ing -hackers)
Karel Zak wrote:
I think command status is common and nice feedback for client. I think
it's more simple change something in JDBC than change protocol that is
shared between more tools.
There is a bit of a queue of changes that would be nice to have but
require a protocol
Resending to the correctly-spelled list alias. Why does postgresql.org
not generate bounces for unknown addresses, anyway?
Original Message
Subject: Re: [PATCHES] Implementing RESET CONNECTION ...
Date: Tue, 04 Jan 2005 13:58:44 +1300
From: Oliver Jowett [EMAIL PROTECTED
Tom Lane wrote:
Kris Jurka [EMAIL PROTECTED] writes:
Also I don't like the idea of cleaning up prepared statements.
Hmm. This seems a bit eye-of-the-beholder-ish, ie you could make a
legitimate argument either way. Maybe the RESET CONNECTION command
should have an option whether to zap prepared
Tom Lane wrote:
Fair point, but you could make the same argument against *any* side
effect of RESET CONNECTION. You're just complaining about PREPARE
because you can see immediately where that breaks JDBC. Anything that
any driver does to set up per-connection state the way it wants will
be
Bruce Momjian wrote:
I see in include/sys/types.h on Solaris 9:
#if defined(_LP64) || defined(_I32LPx)
typedef uint_t nlink_t; /* file link type */
typedef int pid_t; /* process id type */
#else
typedef ulong_t
Peter Eisentraut wrote:
Two comments: First, support for specifying it on configure requires you
to call AC_ARG_VAR (require as in it would prevent people from
shooting themselves in the foot). Please read up on it and add the
appropriate call.
Ok, so that makes sure that the var is hooked
This patch includes LDFLAGS_SL in SHLIB_LINK on most ports (previously
it was only used on AIX and BeOS), and adds support for specifying it in
configure.
This lets you do something like:
./configure LDFLAGS=-static-libgcc LDFLAGS_SL=-static-libgcc
to produce binaries that do not depend on
gcc (3.2.3 on Solaris 9) warns about a couple of places where a pid_t is
formatted with %d by a printf-family function. This patch explicitly
casts to int to suppress the warning.
-O
Index: src/backend/postmaster/pgstat.c
===
RCS
Peter Eisentraut wrote:
Am Freitag, 24. September 2004 09:34 schrieb Oliver Jowett:
Neil Conway wrote:
On Fri, 2004-09-24 at 16:51, Oliver Jowett wrote:
gcc (3.2.3 on Solaris 9) warns about a couple of places where a pid_t is
formatted with %d by a printf-family function.
For curiosity's sake
Alvaro Herrera wrote:
para
!The SQL2003 standard specifies that the keyword
!literalSAVEPOINT/ is mandatory. productnamePostgreSQL/ and
!productnameOracle/ allow the literalSAVEPOINT/literal
!keyword to be omitted. SQL2003 allows only literalWORK/, not
Why are we mentioning
Bruce Momjian wrote:
OK, I like your idea of chaining on to any existing SIGPIPE handler
rather than just do it if none is installed. I also see your fix for
the uninitialized thread-specific variable.
I added some comments to the patch, renamed the pipeheader variable so
it was pg_* to avoid
Bruce Momjian wrote:
Is this 8.0 material?
Tom's already applied it..
-O
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
release savepoint statement ::= RELEASE SAVEPOINT savepoint specifier
Oracle does not have RELEASE SAVEPOINT.
DB2 has RELEASE [ TO ] SAVEPOINT savepoint specifier
I'd vote for RELEASE [ SAVEPOINT ] name (for brevity, and for
consistency
This adds GUC_REPORT to server_encoding and integer_datetimes so they
are reported in the V3 protocol startup packet. Also some related doc
updates.
Rationale:
1) server_encoding is useful to allow clients to detect bad
server/client encoding pairs. The one that bites JDBC regularly is
Oliver Jowett wrote:
This adds GUC_REPORT to server_encoding and integer_datetimes so they
are reported in the V3 protocol startup packet.
s/startup packet/startup process/
-O
---(end of broadcast)---
TIP 6: Have you searched our list archives
Making the assumption that we want standards-conforming syntax here, I
went ahead and did the necessary changes:
Oliver Jowett wrote:
Comments:
1) We have a different syntax to the SQL200n draft (and Oracle by the
looks of it) for ROLLBACK. The draft says:
rollback statement ::= ROLLBACK
Here's a patch that allows parameterized queries to be used in a DECLARE
CURSOR statement.
Previously, the DECLARE would succeed but any FETCHes would fail as the
parameter values supplied to DECLARE were not propagated to the portal
it created. This patch adds that propagation. See
Tom Lane wrote:
So what you'd basically need is a separate signal to trigger that sort
of exit, which would be easy ... if we had any spare signal numbers.
What about multiplexing it onto an existing signal? e.g. set a
shared-mem flag saying exit after cancel then send SIGINT?
I guess this is
Barry Lind wrote:
The other thing that I have been meaning to say in this thread is that I
don't like using COMMIT to mean subtransaction commit (vs. introducing a
new command for it) because of the following situation.
Lets say that I have a java method that takes a jdbc connection and this
30 matches
Mail list logo
