Tzahi Fadida wrote:
I think the solution can be either changing the FETCH_ALL to
INT_MAX or changing the interface parameter count and subsequent usages
to long.
I think changing SPI_cursor_fetch() and SPI_cursor_move() to take a
long for the count parameter is the right fix for HEAD. It would
Hi,
What to people think about having an optional maintenance window so
that autovac only takes action during an approved time.
This sounds like a realy good idea to me!
Sander.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Neil Conway wrote:
I think changing SPI_cursor_fetch() and SPI_cursor_move() to take a
long for the count parameter is the right fix for HEAD.
Attached is a patch that implements this. A bunch of functions had to be
updated: SPI_execute(), SPI_execute_snapshot(), SPI_exec(), SPI_execp(),
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
On 2005-05-01, Neil Conway [EMAIL PROTECTED] wrote:
Tzahi Fadida wrote:
I think the solution can be either changing the FETCH_ALL to
INT_MAX or changing the interface parameter count and subsequent usages
to long.
I think changing SPI_cursor_fetch() and SPI_cursor_move() to take a
long for
Neil Conway wrote:
Neil Conway wrote:
I think changing SPI_cursor_fetch() and SPI_cursor_move() to take a
long for the count parameter is the right fix for HEAD.
Attached is a patch that implements this. A bunch of functions had to be
updated: SPI_execute(), SPI_execute_snapshot(), SPI_exec(),
Thomas Hallgren wrote:
Since both int and long are types whos size that vary depending on
platform, and since the SPI protocol often interfaces with other
languages where the sizes are fixed
ISTM there are no languages where the sizes are fixed. In this
context, int and long are C and C++
On Sun, May 01, 2005 at 03:09:37PM +0300, [EMAIL PROTECTED] wrote:
Process A start to update / insert some rows in a table
and then the connection of process A is lost to PostgreSQL
before it sends commit or rollback. Other processes want to
update the same rows or SELECT
..FOR UPDATE
Alvaro Herrera wrote:
On Sun, May 01, 2005 at 03:09:37PM +0300,
[EMAIL PROTECTED] wrote:
Process A start to update / insert some rows in a table
and then the connection of process A is lost to PostgreSQL
before it sends commit or rollback. Other processes want to
update the same rows
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.
If the other end of a tcp/ip connection just disapears, for example if the
network cable is cut off then in
---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 2005-05-01, Peter Eisentraut [EMAIL PROTECTED] wrote:
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 have until it finishes. In fact, it
keeps sending data 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 have until
Neil Conway wrote:
Thomas Hallgren wrote:
Since both int and long are types whos size that vary depending on
platform, and since the SPI protocol often interfaces with other
languages where the sizes are fixed
ISTM there are no languages where the sizes are fixed. In this
context, int and long
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 else that need
it can implement or sponsor it. Postgresql gets as good as we make it and
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 else that
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 lost.
If Postgres can tell the connection has been lost then it should roll
back the
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 lost.
If
Is there a readme somewhere on how modules are supposed to use custom
GUC variables? If there is I have missed it.
cheers
andrew
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining
On Sat, 30 Apr 2005, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Regarding the secret code stuff - I predict that it will quickly bite
whoever does it, unless they are extremely lucky.
Yeah. Bruce and I were worrying about this on the phone today.
If a company is doing some work with
On Sat, 30 Apr 2005, Jim C. Nasby wrote:
On Fri, Apr 29, 2005 at 11:21:35PM -0700, Joshua D. Drake wrote:
If money's not an issue anymore, can we get a bigger box to host
pgfoundry on then? :)
It's been done and is in the process of being brought up at a new colo
facility. There is also a backup
Thomas Hallgren wrote:
What I meant was that SPI will interface with languages where there is
no correspondence to a type who's size varies depending on platform and
that it therefore would be better to chose a type who's size will not vary.
My point is that since they are different types, the
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
[EMAIL PROTECTED] wrote:
statement_timeout is not a solution if many processes are
waiting the resource.
Why not?
I think the only problem with using statement_timeout for this purpose
is that the client connection might die during a long-running
transaction at a point when no statement is
Neil Conway wrote:
[EMAIL PROTECTED] wrote:
statement_timeout is not a solution if many processes are
waiting the resource.
Why not?
I think the only problem with using statement_timeout for this purpose
is that the client connection might die during a long-running
transaction at a point when
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:
Listen Tom, write a client software that releases the
resources / locks that was hold
Oliver Jowett wrote:
I raised this a while back on -hackers:
http://archives.postgresql.org/pgsql-hackers/2005-02/msg00397.php
but did not get much feedback.
Perhaps you can interpret silence as consent? :)
Does anyone have comments on that email?
I wouldn't be opposed to it. It would be
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?
While that isn't an unreasonable issue on its face, I think it really
boils down to this: the OP is complaining because he thinks the
Neil Conway [EMAIL PROTECTED] writes:
Does anyone have comments on that email?
I wouldn't be opposed to it. It would be different than
statement_timeout, in that we'd be measuring transaction *idle* time,
We would? Why? Please provide a motivation that justifies the
considerably higher
Tom Lane wrote:
We would? Why? Please provide a motivation that justifies the
considerably higher cost to make it count that way, as opposed to
time-since-BEGIN.
The specific scenario this feature is intended to resolve is
idle-in-transaction backends holding on to resources while the network
Tom Lane wrote:
I'm not convinced that Postgres ought to provide
a way to second-guess the TCP stack ... this looks to me like I can't
convince the network software people to provide me an easy way to
override their decisions, so I'll beat up on the database people to
override 'em instead.
On Mon, 2 May 2005 03:05 pm, Neil Conway wrote:
Tom Lane wrote:
We would? Why? Please provide a motivation that justifies the
considerably higher cost to make it count that way, as opposed to
time-since-BEGIN.
The specific scenario this feature is intended to resolve is
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
We would? Why? Please provide a motivation that justifies the
considerably higher cost to make it count that way, as opposed to
time-since-BEGIN.
The specific scenario this feature is intended to resolve is
idle-in-transaction
33 matches
Mail list logo
