SEO

#1 (**permalink**) 04-11-2008, 03:40 AM

> One way to handle this is to have an option, set by
> the client, that
> causes the server to send some ignorable message
> after a given period
> of time idle while waiting for the client. If the
> idleness was due to
> network partitioning or similar failure, then this
> ensures that the
> connection breaks within a known time. This is safer
> than simply having
> the backend abort after a given idle period.

Another option is to have the client driver send some
ignorable message instead of the server. If the
server doesn't get a message every timeout
minutes/seconds + slop factor, then it drops the
connection. So libpq, JDBC, .net etc would all have
to have this implemented, but the changes to the
server would probably be simpler this way, wouldn't they?

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

#2 (**permalink**) 04-11-2008, 03:40 AM

On Mon, May 02, 2005 at 12:29:33 -0700,
Rob Butler <crodster2k@yahoo.com> wrote:
>
> > One way to handle this is to have an option, set by
> > the client, that
> > causes the server to send some ignorable message
> > after a given period
> > of time idle while waiting for the client. If the
> > idleness was due to
> > network partitioning or similar failure, then this
> > ensures that the
> > connection breaks within a known time. This is safer
> > than simply having
> > the backend abort after a given idle period.
>
> Another option is to have the client driver send some
> ignorable message instead of the server. If the
> server doesn't get a message every timeout
> minutes/seconds + slop factor, then it drops the
> connection. So libpq, JDBC, .net etc would all have
> to have this implemented, but the changes to the
> server would probably be simpler this way, wouldn't they?

Except it won't work, because the server is who needs to know about
the problem. If the network is down, you can't send a TCP RST packet
to close the connection on the server side.

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

#3 (**permalink**) 04-11-2008, 03:40 AM

On 2005-05-02, Rob Butler <crodster2k@yahoo.com> wrote:
> Another option is to have the client driver send some
> ignorable message instead of the server. If the
> server doesn't get a message every timeout
> minutes/seconds + slop factor, then it drops the
> connection. So libpq, JDBC, .net etc would all have
> to have this implemented, but the changes to the
> server would probably be simpler this way, wouldn't they?

Then the client has to guarantee that it can stop whatever it was doing
(which might have nothing to do with the database) every so often in
order to send a message; this isn't feasible for most clients.

The server-based method is actually no more complex to implement on the
server end and does not impose any such restrictions on the client (even
if the client sets the option and then ignores the database connection
for a long time, all that happens is that the TCP window fills up).

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

#4 (**permalink**) 04-11-2008, 03:40 AM

Andrew - Supernews <andrew+nonews@supernews.com> writes:
> Then the client has to guarantee that it can stop whatever it was doing
> (which might have nothing to do with the database) every so often in
> order to send a message; this isn't feasible for most clients.

It's certainly infeasible for libpq, which has no portable way to force
the calling app to give it control.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

#5 (**permalink**) 04-11-2008, 03:40 AM

On Mon, 02 May 2005 19:53:56 -0000
Andrew - Supernews <andrew+nonews@supernews.com> wrote:

>The server-based method is actually no more complex to
>implement on the server end and does not impose any such
restrictions on
>the client (even if the client sets the option and then
ignores the database connection
>for a long time, all that happens is that the TCP window
fills up).

Yes, any solution on the client side also requires all
client connection interface to be changed..But, at server
side solution only server side would be changed :-) I dont
know it is complex or not. as you know Oracle has a
parameter to implement that solution on the server side.

Best Regards,

Adnan DURSUN
ASRIN Biliþim Hiz.Ltd.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

#6 (**permalink**) 04-11-2008, 03:41 AM

FWIW, I've found myself wishing I could set statement_timeout on a per user
or per group basis. Likewise for log_min_duration_statement.

On Mon, May 02, 2005 at 11:38:12PM +0300, adnandursun@asrinbilisim.com.tr wrote:
> On Mon, 02 May 2005 19:53:56 -0000
> Andrew - Supernews <andrew+nonews@supernews.com> wrote:
>
> >The server-based method is actually no more complex to
> >implement on the server end and does not impose any such
> restrictions on
> >the client (even if the client sets the option and then
> ignores the database connection
> >for a long time, all that happens is that the TCP window
> fills up).
>
> Yes, any solution on the client side also requires all
> client connection interface to be changed..But, at server
> side solution only server side would be changed :-) I dont
> know it is complex or not. as you know Oracle has a
> parameter to implement that solution on the server side.
>
> Best Regards,
>
> Adnan DURSUN
> ASRIN Bili?im Hiz.Ltd.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>

--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

#7 (**permalink**) 04-11-2008, 03:41 AM

On Mon, 2 May 2005, Jim C. Nasby wrote:

> FWIW, I've found myself wishing I could set statement_timeout on a per user
> or per group basis. Likewise for log_min_duration_statement.
>

See ALTER USER ... SET

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

Re: Feature freeze date for 8.1