We have talked about performance and some new features
before freeze of 8.1. Like ;
·Bitmap indexes
·Autovacuum
·GIS features
·Object-Oriented features
·PITR
·Table Partition
But there is a feature that is too important for a
database. It is ava
---Original Message---
From: Dennis Bjorklund
Date: 05/01/05 17:57:44
To: Alvaro Herrera
Cc: [EMAIL PROTECTED];
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
On Sun, 01 May 2005 11:37:47 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
>Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> The problem, as I understand it, is that if you have a
>long-running
>> query and the client process disappears, the query keeps
>running and
>> holds whatever resources it may
On Sun, 1 May 2005 19:35:01 +0200 (CEST)
Dennis Bjorklund <[EMAIL PROTECTED]> wrote:
>On Sun, 1 May 2005 [EMAIL PROTECTED] 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 el
On Sun, 1 May 2005 14:35:37 -0500
Bruno Wolff III <[EMAIL PROTECTED]> wrote:
>On Sun, May 01, 2005 at 19:57:37 +0300,
> [EMAIL PROTECTED] wrote:
>>
>> Listen Tom, write a client software that releases the
>> resources / locks that was hold before client power is
>down
>> or client connection was
On Mon, 02 May 2005 12:05:45 +1000
Neil Conway <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> statement_timeout is not a solution if many processes
>are
>> waiting the resource.
>
>Why not?
Imagine a process locked some rows to update and process
codes like that ;
-- Sample Clien
On Sun, 1 May 2005 23:08:39 -0500
Jaime Casanova <[EMAIL PROTECTED]> wrote:
>On 5/1/05, [EMAIL PROTECTED]
><[EMAIL PROTECTED]> wrote:
>> On Sun, 1 May 2005 14:35:37 -0500
>> Bruno Wolff III <[EMAIL PROTECTED]> wrote:
>> >On Sun, May 01, 2005 at 19:57:37 +0300,
>> > [EMAIL PROTECTED] wrote:
>> >>
On Mon, 02 May 2005 00:25:33 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
>Jaime Casanova <[EMAIL PROTECTED]> writes:
>> Actually, i can't see what's the problem. :)
>
>I think the issue is "how long does it take for the
>rollback to happen?"
>
> so I'll beat up on the database people to override
On Mon, 02 May 2005 01:35:14 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
>[ itch... ] This seems to me to be conflating several
>distinct issues.
>AFAIR the points that have been raised in the thread are:
>
>#1 Defend against loss of connectivity to client
>#2 Defend against client sitting idle
On Mon, 02 May 2005 16:07:07 +1000
Neil Conway <[EMAIL PROTECTED]> wrote:
>> I claim that if you have a problem with #1 you ought to
>go discuss it with some TCP hackers: you basically want to
second-guess the TCP
>> stack's ideas about appropriate timeouts.
>
>Well, no -- you might want to set a
On Mon, 2 May 2005 10:11:40 +0200
Peter Eisentraut <[EMAIL PROTECTED]> wrote:
>I was under the impression that the specific scenario is
>busy-in-transaction backends continuing to produce and
>send data while the client has disappeared. Why does the
backend ignore network errors
>and keep send
On Mon, 02 May 2005 13:59:21 +0300
Hannu Krosing <[EMAIL PROTECTED]> wrote:
>On E, 2005-05-02 at 01:35 -0400, Tom Lane wrote:
>Well, I've had problems with clients which resolve DB
timeouts by
>closing the current connection and establish a new one.
>
>If it is actual DB timeout, then it all is o
On Sun, 01 May 2005 22:23:19 +0300
Hannu Krosing <[EMAIL PROTECTED]> wrote:
>On P, 2005-05-01 at 11:37 -0400, Tom Lane wrote:
>Im my case all ttransactions were implicit one command
functon calls
>("select * from dbfunc()"), so transaction timeout would
not help.
>
>probably the only way for serve
On Mon, 02 May 2005 13:32:18 +0200
Alvar Freude <[EMAIL PROTECTED]> wrote:
>Hi,
>
>-- Dennis Bjorklund <[EMAIL PROTECTED]> wrote:
>
>> The tcp hackers have provided an api for clients to set
>these values per
>> socket (setsockopt with TCP_KEEPIDLE and similar (in
>linux at least)).
>
>you can use
On Mon, 2 May 2005 18:47:14 +0300 (EEST)
Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>FWIW, I've been bitten by this problem twice with other
>applications.
>
>1. We had a DB2 database with clients running in other
>computers in the network. A faulty switch caused random
>network outages. If th
On Mon, 02 May 2005 19:53:56 -
Andrew - Supernews <[EMAIL PROTECTED]> 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 connecti
On Tue, 3 May 2005 13:02:46 -0500
"Dave Held" <[EMAIL PROTECTED]> wrote:
>How about an optional second connection to send keepalive
>pings?
>It could be unencrypted and non-blocking. If
authentication is needed
>on the ping port (which it doesn't seem like itwould
needto be),
>it could be very
17 matches
Mail list logo
