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 configuration of the
TCP_KEEPCNT / TCP_KEEPIDLE / TCP_KEEPINTVL socket options on backend
s
Neil Conway wrote:
As I said before, we may or may not want to change
the executor itself to use a constant-sized type, but as a matter of
interface definition, I think using "long" makes the most sense.
One thing that I forgot. If you indeed will do something like that in
the future, the implic
On Mon, 2 May 2005, Tom Lane wrote:
> #1 Defend against loss of connectivity to client
>
> 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. Maybe you know what yo
Tom Lane wrote:
#3 Defend against client holding locks unreasonably long, even though
not idle
I can't get too excited about this case. If the client is malicious,
this feature is surely insufficient to stop them from consuming a lot of
resources (for example, they could easily drop and then
Russell Smith <[EMAIL PROTECTED]> writes:
> I would prefer an idle timeout if it's not costly. Because otherwise
> estimates need to be made about how long VACUUM and backup could take,
> and set the timeout longer.
Why? No one has suggested that the same timeout must be applied to
every connect
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 configuration of the
> TCP_KEEPCNT / TCP_KEEPIDLE / TCP_KEEPINTVL socket options on backend
> soc
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-transacti
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
> idle
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. Perhap
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
c
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 high
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
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 differen
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
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
[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 curr
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 connect
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 la
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 b
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 wit
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 column'
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 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 t
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 [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
nothi
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 lon
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 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 t
---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
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 it finishes.
There is a trivial solution for this: it's called st
Neil Conway <[EMAIL PROTECTED]> writes:
> The reason the API types should use "long" is that the underlying
> executor APIs (e.g. ExecutorRun()) use "long". It might be a good idea
> to change the executor stuff to use int64s
No, it would not. There is a potential performance cost ("long" shoul
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
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 s
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
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++ type
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(
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
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
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(),
SPI
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
40 matches
Mail list logo
