Bruce Momjian wrote:
OK, updated patch, with output of text bind parameters. New output is:
LOG: prepare sel1: SELECT $1 + $2;
LOG: bind sel1: SELECT $1 + $2;
LOG: bind sel1: parameter 1: "8"
LOG: bind sel1: parameter 2: "5"
LOG: execut
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:
> 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
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 -- ra
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 pre
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
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)
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
Christopher Kings-Lynne wrote:
What would be absolutely ideal is a reset connection command, plus some
way of knowing via the protocol if it's needed or not.
And a way of notifying the client that a reset has happened.
-O
---(end of broadcast)--
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
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_coun
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
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
opt
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 configu
(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 version
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, RESE
Karel Zak wrote:
I still don't see a big difference between DEALLOCATE and RESET -- both
can break the JDBC driver.
You have to go out of your way to break the driver via DEALLOCATE,
explicitly finding a statement name that the driver is using. There's
also a reasonably simple fix: make the proto
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 equal
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 prepare
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:
AFAICS the only nondestructive way to do this is to cvs delete and cvs
add, with a commit comment saying where the files were moved from. Then
when you are looking at them in CVS, you'd have to navigate over to the
previous location (by hand, probably; the commit comment isn't goin
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 in
Oliver Jowett wrote:
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.
Any feedback on this patch? Can it get applied for 8.0?
-O
---(end of broadcast
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
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, what formatting escape does gcc prefer?
I don't think there is an escape
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 fi
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 lib
Alvaro Herrera wrote:
!The SQL2003 standard specifies that the keyword
!SAVEPOINT is mandatory. PostgreSQL and
!Oracle allow the SAVEPOINT
!keyword to be omitted. SQL2003 allows only WORK, not
Why are we mentioning Oracle behavior at all?
One of the influences on the SAVEPOIN
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
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 name
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
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
client_
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
::= RELEASE SAVEPOINT
Oracle does not have RELEASE SAVEPOINT.
DB2 has RELEASE [ TO ] SAVEPOINT
I'd vote for RELEASE [ SAVEPOINT ] (for brevity, and for
consistency with ROLLBACK). I feel no urge to copy DB2.
Here's
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 [ WORK ] [ AND [ NO
Tatsuo Ishii wrote:
Tom Lane wrote:
If I understood what I was reading, this would take several things:
* Remove the "special UTF-8 check" in pg_verifymbstr;
* Extend pg_utf2wchar_with_len and pg_utf_mblen to handle the 4-byte case;
* Set maxmblen to 4 in the pg_wchar_table[] entry for UTF-8.
Are
Tom Lane wrote:
If I understood what I was reading, this would take several things:
* Remove the "special UTF-8 check" in pg_verifymbstr;
* Extend pg_utf2wchar_with_len and pg_utf_mblen to handle the 4-byte case;
* Set maxmblen to 4 in the pg_wchar_table[] entry for UTF-8.
Are there any other place
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 g
Andreas Pflug wrote:
Tom Lane wrote:
If you don't mind plastering a "use at your own risk" sign on it, then
go for it.
killing a backend is obviously much more "at your own risk" than a
descent function.
[...]
What about implementing "kill" as "cancel then exit"? Does that
guarantee a safe exit
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
http://arc
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Patch attached (surprinsingly small), though it only applies with the
savepoint patch applied(*). If any driver writer wants to play, however,
it's easy to see what's going on -- a ParameterStatus message will be
received from the backend
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
c
Per discussion on -hackers
(http://archives.postgresql.org/pgsql-hackers/2004-05/msg00990.php),
here is a first cut at delaying query planning for unnamed statements
until we have concrete parameters (i.e. at Bind).
This passes 'make check' (not particularly informative since that
doesn't exer
43 matches
Mail list logo
