-------Original Message-------

From: Dennis Bjorklund
Date: 05/01/05 17:57:44
To: Alvaro Herrera
Cc: adnandursun@asrinbilisim.com.tr;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Feature freeze date for 8.1

On Sun, 1 May 2005, Alvaro Herrera wrote:

> Well, if process A loses the connection to the client,
then the
> transaction will be rolled back and other processes will
be able to
> continue.

Never. Process do waits until it is killed or canceled. for
example unplugged network cable or crashes client machine
or in case of lost of network connection

>If the other end of a tcp/ip connection just disapears,
for example if the
>network cable is cut off then in linux it can take up to 2
hours as
>default for it to close the connection. Normally if a
client application
>dies then the client OS cleans up and closes the socket so
that the server
>knows about it.


>There are some settings that one can alter to change the
time it waits
>before probing and killing the connection, ie
tcp_keepalive_time in
>/proc/sys/net/ipv4/.

But TCP experts don't advice to change this setting.However
this is not suitable method for this purposes..

>It's documented in "man tcp" that say that it will take
2h11m as default
>to kill of such a connection.

>Pg could of course also implement some pinging protocl
that should be done
>every now and then by the client so that the server knows
that it is
>alive. For now you just have to lower the global settings
as the one above
>if you want it to handle it better.

If a database wants to get bigger on the usage these
settings like this must be implemented.tcp_keepalive_time
setting is for TCP. It is not for database connection. if
so, Oracle also recommends it. But we advice to ppl to use
PostgreSQL instead of Oracle and others because it is open
source.. And how we convince the ppl who wants to use
PostgreSQL. What do we recommend the ppl ? :
1. change tcp_keepalive_time setting or
2. restart database or
3. find and kill the pid etc..

This is not good things for them.

We sometime discuss here for geographic system datatypes
and feature. First, a database must have real database
features, not extreme features.

Best Regards

Adnan DURSUN
ASRIN Biliþim Ltd.Þti


---------------------------(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



---------------------------(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

On Sun, 1 May 2005 adnandursun@asrinbilisim.com.tr wrote:

> If a database wants to get bigger on the usage these settings like this
> must be implemented.

Lucky thing that postgresql is open source so you or anyone else that need
it can implement or sponsor it. Postgresql gets as good as we make it and
nothing happens unless someone that need a feature sit down and implement
it.

> First, a database must have real database features, not extreme
> features.

Different people have different needs. For me this have not even once been
a problem, so it's not something that I personally will lose any sleep
over. It doesn't mean I wouldn't welcome that someone else work on it.

--
/Dennis Björklund


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

On Sun, 1 May 2005 19:35:01 +0200 (CEST)
Dennis Bjorklund <db@zigo.dhs.org> wrote:
>On Sun, 1 May 2005 adnandursun@asrinbilisim.com.tr wrote:
>
>> If a database wants to get bigger on the usage these
>settings like this
>> must be implemented.
>
>Lucky thing that postgresql is open source so you or
>anyone else that need
>it can implement or sponsor it. Postgresql gets as good as
>we make it and
>nothing happens unless someone that need a feature sit
>down and implement
>it.

Yes, i agree with you so i havent' sit down and i discuss
with you a feature that will be getting more availability
to PostgreSQL database.All the thing that i want is to get
large usage PostgreSQL in my country. I discuss a lot of
ppl about postgresql database and i try to convince the ppl
to use the PostgreSQL.

>> First, a database must have real database features, not
>extreme
>> features.
>
>Different people have different needs. For me this have
>not even once been
>a problem, so it's not something that I personally will
>lose any sleep
>over. It doesn't mean I wouldn't welcome that someone else
>work on it.

Yes, but you have developed a database application so,
there are a few principal features must be added instead of
extreme features.

I would never wait a minute to join postgresql
development group, if i knew enough C/C++ . I can do only
to talk ppl and convince them to use open source software
like PostgreSQL. The features that we discuss here to grown
up the usage of the PostgreSQL database. I am a DBA. I know
some other databases like Oracle, MSSQL etc.

Adnan DURSUN
ASRIN Bilisim Hiz.Ltd.

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Centuries ago, Nostradamus foresaw when adnandursun@asrinbilisim.com.tr would write:
> We sometime discuss here for geographic system datatypes
> and feature. First, a database must have real database
> features, not extreme features.

Oh, but it would be so much better if we could call the next version
"PostgreSQL 8.1 Extreme Edition"
because it was so much more "extreme."

That way we could get skateboarders to do promotional appearances.
And Vin Diesel for a "XXX" appearance... :-)
--
let name="cbbrowne" and tld="gmail.com" in String.concat "@" [name;tld];;
http://cbbrowne.com/info/slony.html
Signs of a Klingon Programmer - 4. "You cannot really appreciate
Dilbert unless you've read it in the original Klingon."

>>Well, if process A loses the connection to the client,
>
> then the
>
>>transaction will be rolled back and other processes will
>
> be able to
>
>>continue.
>
>
> Never. Process do waits until it is killed or canceled. for
> example unplugged network cable or crashes client machine
> or in case of lost of network connection

Always. That's how it works for me.

Chris

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