Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
> >>And btw I lost track of the thread. was any actual feature freeze date
> >>for 8.1 approved?
> >>
> >>
> >
> >July 1 is the plan ... subject to change of course ...
> >
> >
> >
> >
>
> Incidentally, the way this was discussed/announced has
Tom Lane wrote:
And btw I lost track of the thread. was any actual feature freeze date
for 8.1 approved?
July 1 is the plan ... subject to change of course ...
Incidentally, the way this was discussed/announced has been just right,
IMHO. Big improvement over last year.
cheers
andrew
Kaare Rasmussen <[EMAIL PROTECTED]> writes:
>> This has very little to do with "Feature freeze date for 8.1"...
> And btw I lost track of the thread. was any actual feature freeze date
> for 8.1 approved?
July 1 is the plan ... subject to change of course ...
regards, tom
> This has very little to do with "Feature freeze date for 8.1"...
And btw I lost track of the thread. was any actual feature freeze date for 8.1
approved?
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://
Any chance one of you fine people could start another thread?
This has very little to do with "Feature freeze date for 8.1"...
Thanks,
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Dave Held wrote:
> So it seems that a possible solution to that problem is to
> have a separate connection for keepalive packets that doesn't
> block and doesn't interfere with normal client/server
> communication.
What does this do that TCP keepalives don't? (other than add extra
connection man
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Dave Held
> Sent: Tuesday, May 03, 2005 3:41 PM
> To: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Feature freeze date for 8.1
>
> > -Original
Tom Lane <[EMAIL PROTECTED]> writes:
> "Dave Held" <[EMAIL PROTECTED]> writes:
>> 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 it would need
>> to be), it c
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 03, 2005 4:20 PM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Feature freeze date for 8.1
>
>
> "Dave Held" <[EMAIL PROTECTED]&g
OTECTED]; Peter Eisentraut; Alvaro Herrera;
> > pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] Feature freeze date for 8.1
> >
> > [...]
> > BTW, the upthread proposal of just dropping the message (which is what
> > O_NONBLOCK would do) doesn't wo
"Dave Held" <[EMAIL PROTECTED]> writes:
> 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 it would need
> to be), it could be very simple, like this:
> * client
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 03, 2005 3:36 PM
> To: Dave Held; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Feature freeze date for 8.1
>
> [...]
> Yes, this looks like good.Bu
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
t; Subject: Re: [HACKERS] Feature freeze date for 8.1
>
> [...]
> BTW, the upthread proposal of just dropping the message (which is what
> O_NONBLOCK would do) doesn't work; it will lose encryption sync on SSL
> connections.
How about an optional second connection to send keep
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Does statement_timeout fire on that scenario? How about the new
> transaction_timeout option discussed in other threads?
Probably neither, since very likely you aren't in a transaction at all.
I'd not expect the server to send these messages except
On Tue, 3 May 2005, Tom Lane wrote:
I am a tad worried about the possibility that if the client does nothing
for long enough, the TCP output buffer will fill causing the backend to
block at send(). A permanently blocked backend is bad news from a
performance point of view (it degrades the sinval p
t; Subject: Re: [HACKERS] Feature freeze date for 8.1
>
> [...]
> I am a tad worried about the possibility that if the client
> does nothing for long enough, the TCP output buffer will fill
> causing the backend to block at send(). A permanently blocked
> backend is bad news from
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> What we can do in PostgreSQL is to introduce an application-level
>> heartbeat. A simple "Hello world" message sent from server to client that
>> the client would ignore would do the trick.
> Actually we would need a round-trip indicator (some there-a
On E, 2005-05-02 at 18:47 +0300, Heikki Linnakangas wrote:
> On Mon, 2 May 2005, Hannu Krosing wrote:
> > It would be nice if I coud st up some timeut using keepalives (like ssh-
> > s ProtocoKeepalives") and use similar timeouts on client and server.
>
> FWIW, I've been bitten by this problem tw
On 5/2/05, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> What we can do in PostgreSQL is to introduce an application-level
> heartbeat. A simple "Hello world" message sent from server to client that
> the client would ignore would do the trick.
Hmm, a quick-and-dirty implementation could be that
> -Original Message-
> From: Oliver Jowett [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 02, 2005 3:06 PM
> To: Chuck McDevitt
> Cc: Tom Lane; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Feature freeze date for 8.1
>
> Chuck McDevi
Chuck McDevitt wrote:
> Why not just use SO_KEEPALIVE on the TCP socket?
We already do, but the default keepalive interval makes it next to useless.
-O
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
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)---
T
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: Monday, May 02, 2005 1:17 PM
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Feature freeze date for 8.1
&g
Tom Lane wrote:
> Wouldn't it be reasonable to expect the "cluster liveness machinery" to
> notify the database server's kernel that connections to A are now dead?
> I find it really unconvincing to suppose that the above problem should
> be solved at the database level.
Actually, if you were to
Tom Lane wrote:
> Wouldn't it be reasonable to expect the "cluster liveness machinery" to
> notify the database server's kernel that connections to A are now dead?
No, because it's a node-level liveness test, not a machine-level
liveness. It's possible that all that happened is the node's VM cras
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, [EMAIL PROTECTED] wrote:
> On Mon, 02 May 2005 19:53:56 -
> Andrew - Supernews <[EMAIL PROTECTED]> wrote:
>
> >Th
Hi,
-- [EMAIL PROTECTED] wrote:
> So this means, If client does never try to send data the
> resources would be going to be held.
> I think it is not a good solution to find zombie / dead
> connection and clear them..
With TCP/IP you DON'T have any other options then waiting for a timeout. In
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
Andrew - Supernews <[EMAIL PROTECTED]> 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, whic
On 2005-05-02, Rob Butler <[EMAIL PROTECTED]> 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 wou
On Mon, May 02, 2005 at 12:29:33 -0700,
Rob Butler <[EMAIL PROTECTED]> 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
> > id
> 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
> co
On 2005-05-02, Tom Lane <[EMAIL PROTECTED]> wrote:
> 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
> connection-loss timeout mandated by the TCP RFCs is too long. Perhaps
> the OP knows network engineering fa
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, 2 May 2005, Hannu Krosing 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 ok, the server soon notices
that the client connection is closed and kills itself.
Problems h
Oliver Jowett <[EMAIL PROTECTED]> writes:
> The scenario I need to deal with is this:
> There are multiple nodes, network-separated, participating in a cluster.
> One node is selected to talk to a particular postgresql instance (call
> this node A).
> A starts a transaction and grabs some locks i
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> 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 sending data?
There are a couple
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] belched out:
> 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
>>> resour
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] 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
"Postg
The world rejoiced as matthew@zeut.net ("Matthew T. O'Connor") wrote:
> Marc G. Fournier wrote:
>
>> On Fri, 29 Apr 2005, Christopher Browne wrote:
>>
>>> Some reasonable approximations might include:
>>> - How much disk I/O was recorded in the last 60 seconds?
>>> - How many application transactio
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
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 SO_KEEPALIVE:
[...] SO_KEEPALIVE enables
the periodic transmission of messages
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: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 E, 2005-05-02 at 01:35 -0400, Tom Lane wrote:
> 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 scena
On P, 2005-05-01 at 11:37 -0400, Tom Lane 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 it finish
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 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, 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 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 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 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
Peter Eisentraut wrote:
> Neil Conway wrote:
>
>>The specific scenario this feature is intended to resolve is
>>idle-in-transaction backends holding on to resources while the
>>network connection times out;
>
>
> I was under the impression that the specific scenario is
> busy-in-transaction bac
Neil Conway wrote:
> The specific scenario this feature is intended to resolve is
> idle-in-transaction backends holding on to resources while the
> network connection times out;
I was under the impression that the specific scenario is
busy-in-transaction backends continuing to produce and send d
Neil Conway wrote:
Is there a way to change the
socket timeout for some subset of the processes on the machine without
hacking the client or server source?
The only ways I can see of tuning the TCP idle parameters on Linux are
globally via sysfs, or per-socket via setsockopt().
You could LD_PRE
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
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
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
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
---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
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
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
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
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
Marc G. Fournier wrote:
On Fri, 29 Apr 2005, Christopher Browne wrote:
Some reasonable approximations might include:
- How much disk I/O was recorded in the last 60 seconds?
- How many application transactions (e.g. - invoices or such) were
issued in the last 60 seconds (monitoring a sequence cou
On Fri, 29 Apr 2005, Christopher Browne wrote:
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] ("Marc G. Fournier") wrote:
I know one person was talking about being able to target only those
that pages that have changes, instead of the whole table ... but some
sort of "load monitoring"
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] ("Marc G.
Fournier") wrote:
> I know one person was talking about being able to target only those
> that pages that have changes, instead of the whole table ... but some
> sort of "load monitoring" that checks # of active connections and
I think what you're suggesting is that vacuum settings (most likely
delay) take into consideration the load on the database, which I think
is a great idea. One possibility is if vacuum tracks how many blocks
it's read/written, it can see how many blocks the database has done
overall; subtract the t
On Fri, 29 Apr 2005, Tom Lane wrote:
"Matthew T. O'Connor" writes:
What to people think about having an optional "maintenance window" so
that autovac only takes action during an approved time. But perhaps
just using the vacuum delay settings will be enough.
I'm not sure autovac should go complete
"Matthew T. O'Connor" writes:
> What to people think about having an optional "maintenance window" so
> that autovac only takes action during an approved time. But perhaps
> just using the vacuum delay settings will be enough.
I'm not sure autovac should go completely catatonic during the day;
On Fri, Apr 29, 2005 at 12:43:37 -0300,
"Marc G. Fournier" <[EMAIL PROTECTED]> wrote:
> On Fri, 29 Apr 2005, Bruno Wolff III wrote:
>
> Except for the surprise of peridically having the system go unresponsive
> because it hit a large table, and that new user wondering what is wrong
> with post
On Fri, 29 Apr 2005, Bruno Wolff III wrote:
On Fri, Apr 29, 2005 at 10:09:43 -0400,
Bruce Momjian wrote:
Tom Lane wrote:
Christopher Browne <[EMAIL PROTECTED]> writes:
In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian) wrote:
o integrated auto-vacuum (Bruce)
If this can kick of
Tom Lane wrote:
Christopher Browne <[EMAIL PROTECTED]> writes:
If this can kick off a vacuum of a Very Large Table at an unfortunate
time, this can turn out to be a prety painful misfeature.
[ shrug... ] You'll always be able to turn it off if you don't want it.
I'm not sure that we'll be
On Fri, Apr 29, 2005 at 10:09:43 -0400,
Bruce Momjian wrote:
> Tom Lane wrote:
> > Christopher Browne <[EMAIL PROTECTED]> writes:
> > > In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian)
> > > wrote:
> > >> o integrated auto-vacuum (Bruce)
> >
> > > If this can kick off a vac
Tom Lane wrote:
> Christopher Browne <[EMAIL PROTECTED]> writes:
> > In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian) wrote:
> >> o integrated auto-vacuum (Bruce)
>
> > If this can kick off a vacuum of a Very Large Table at an unfortunate
> > time, this can turn out to be a pre
Christopher Browne <[EMAIL PROTECTED]> writes:
> In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian) wrote:
>> o integrated auto-vacuum (Bruce)
> If this can kick off a vacuum of a Very Large Table at an unfortunate
> time, this can turn out to be a prety painful misfeature.
[ sh
In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian) wrote:
> o integrated auto-vacuum (Bruce)
If this can kick off a vacuum of a Very Large Table at an unfortunate
time, this can turn out to be a prety painful misfeature.
What I'd _really_ love to see (and alas, it's beyond
Bruce Momjian wrote:
You might remember that when we released 8.0, the plan was to have a
12-month development cycle for 8.1, unless there were Win32 problems
that required complex fixes, in which case we would have a shorter 8.1
cycle.
Well the good news is that there have been almost no Win32 pro
As a user, I would definetly prefer to see 8.1
released sooner with the feature set listed below,
than wait another 6+ months for a few other features.
Additionally, the beta may go smoother/faster if you
don't have too many huge features going in at once.
Just my opinion.
Later
Rob
--- Bruce Mom
On Thu, Apr 28, 2005 at 09:02:40 -0400,
Bruce Momjian wrote:
> Well the good news is that there have been almost no Win32 problems, but
> the other good news is that we are getting a lot of powerful features
> for 8.1 already:
You forgot to list the indexed aggregate feature for max and min. Wh
100 matches
Mail list logo
