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
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?
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 lane
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
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 been just right,
IMHO. Big
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 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 twice
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-and-back
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 03, 2005 9:31 AM
To: Hannu Krosing
Cc: Heikki Linnakangas; Neil Conway; Oliver Jowett;
[EMAIL PROTECTED]; Peter Eisentraut; Alvaro Herrera;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Feature
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
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
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 03, 2005 12:39 PM
To: Heikki Linnakangas
Cc: Hannu Krosing; Neil Conway; Oliver Jowett;
[EMAIL PROTECTED]; Peter Eisentraut; Alvaro Herrera;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Feature
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 simple,
-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.But ;
1. Do client interfaces (ODBC
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 connects
-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 work; it will lose encryption sync on SSL
connections.
How about an optional second connection to send
-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] writes:
How about an optional second connection to send
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 could be very
-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 Message-
From: Tom Lane [mailto
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
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
sockets?
[
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 connection.
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
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 you
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
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
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 backends
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 Client Codes
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:
Listen Tom, write
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
'em instead.
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 while
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 sending
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 finishes.
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 scenario this feature
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 ok, the
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 server to
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
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 SO_KEEPALIVE:
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 transactions (e.g. -
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
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
resources / locks that
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 of
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 in the
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
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 the
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 far
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
connection
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
idleness was due
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 would all
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, which
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 connection
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
one
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:
The
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
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
-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
Andrew - Supernews [EMAIL
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)---
TIP
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
-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 McDevitt wrote:
Why not just use
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
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 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
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
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
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
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
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.
[ shrug...
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 prety painful
On Fri, Apr 29, 2005 at 10:09:43 -0400,
Bruce Momjian pgman@candle.pha.pa.us 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
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, 29 Apr 2005, Bruno Wolff III wrote:
On Fri, Apr 29, 2005 at 10:09:43 -0400,
Bruce Momjian pgman@candle.pha.pa.us 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)
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 postgresql
Matthew T. O'Connor matthew@zeut.net 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
On Fri, 29 Apr 2005, Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net 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
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
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
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
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
On Thu, Apr 28, 2005 at 09:02:40 -0400,
Bruce Momjian pgman@candle.pha.pa.us 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
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
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
98 matches
Mail list logo
