Gaetano Mendola wrote:
Hi all,
it seems that the stats collector on my box is using more CPU than
it did in the past.
This is a known bug that was fixed in 8.2.4, so you need to upgrade.
//Magnus
---(end of broadcast)---
TIP 7: You can help
On Mon, Oct 29, 2007 at 09:52:24AM +0100, Gaetano Mendola wrote:
it seems that the stats collector on my box is using more CPU than
it did in the past.
it's well known bug, and it was fixed in 8.2.4:
http://www.postgresql.org/docs/current/interactive/release-8-2-4.html
...
Prevent the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
it seems that the stats collector on my box is using more CPU than
it did in the past.
This is what I'm observing:
CPU usage for the stat process: 25% flat
$ psql -c select version()
version
-
hubert depesz lubaczewski wrote:
On Mon, Oct 29, 2007 at 09:52:24AM +0100, Gaetano Mendola wrote:
it seems that the stats collector on my box is using more CPU than
it did in the past.
it's well known bug, and it was fixed in 8.2.4:
hubert depesz lubaczewski wrote:
On Mon, Oct 29, 2007 at 09:52:24AM +0100, Gaetano Mendola wrote:
it seems that the stats collector on my box is using more CPU than
it did in the past.
it's well known bug, and it was fixed in 8.2.4:
Gaetano Mendola wrote:
hubert depesz lubaczewski wrote:
On Mon, Oct 29, 2007 at 09:52:24AM +0100, Gaetano Mendola wrote:
it seems that the stats collector on my box is using more CPU than
it did in the past.
it's well known bug, and it was fixed in 8.2.4:
Andrew Dunstan wrote:
Gaetano Mendola wrote:
hubert depesz lubaczewski wrote:
On Mon, Oct 29, 2007 at 09:52:24AM +0100, Gaetano Mendola wrote:
it seems that the stats collector on my box is using more CPU than
it did in the past.
it's well known bug, and it was
Magnus Hagander wrote:
Gaetano Mendola wrote:
hubert depesz lubaczewski wrote:
On Mon, Oct 29, 2007 at 09:52:24AM +0100, Gaetano Mendola wrote:
it seems that the stats collector on my box is using more CPU than
it did in the past.
it's well known bug, and it was fixed in 8.2.4:
Gaetano Mendola wrote:
hubert depesz lubaczewski wrote:
On Mon, Oct 29, 2007 at 09:52:24AM +0100, Gaetano Mendola wrote:
it seems that the stats collector on my box is using more CPU than
it did in the past.
it's well known bug, and it was fixed in 8.2.4:
* Tom Lane:
I am fairly sure that this bug explains problems previously reported
by Merlin Moncure:
http://archives.postgresql.org/pgsql-general/2006-10/msg01312.php
and Florian Weimer:
http://archives.postgresql.org/pgsql-general/2006-11/msg00305.php
In both those cases, off-list
* Joshua D. Drake:
If you need obfuscation (and you don't, you just think you do, no
offense) use C.
Or put the relevant code into some package/module/whatever, stored on
the file system, and include that.
--
Florian Weimer[EMAIL PROTECTED]
BFK edv-consulting GmbH
LS,
I don't know if this is the right mailing list to post my request. But here
it goes. PostgreSQL has greatly support for data types inet and cidr. But so
far I haven't been able to figure out how one would convert a ip/netmask
(what one will find on a network card) pair into a network cidr.
Hi All,
I am giving the command
cat config.log|grep -w 'PG_VERSION'
Which gives the following Output:
| #define PG_VERSION 8.3beta2
| #define PG_VERSION 8.3beta2
| #define PG_VERSION 8.3beta2
| #define PG_VERSION 8.3beta2
| #define PG_VERSION 8.3beta2
| #define PG_VERSION 8.3beta2
| #define
Leaving aside the question of why one might want to do this, Unix 101
should show you many ways to do it. For example,
sed -n -e 's/.*PG_VERSION /PG_VERSION /p' -e /PG_VERSION/q config.log
Please don't cross-post questions like this, especially when it's not
really a PostgreSQL question at
On Fri, Oct 26, 2007 at 6:39 PM, in message
[EMAIL PROTECTED], Jeff Davis [EMAIL PROTECTED]
wrote:
On Fri, 2007-10-26 at 18:06 -0500, Kevin Grittner wrote:
Hmmm... We would actually prefer to get the WAL file at the
specified interval. We have software to ensure that the warm
standby
On Fri, Oct 26, 2007 at 6:28 PM, in message
[EMAIL PROTECTED], Jeff Davis [EMAIL PROTECTED]
wrote:
[ of course, there's no guarantee that the archive_command succeeds in
that time ]
Which is one of the things we would want to cause an alert.
-Kevin
---(end
On Fri, Oct 26, 2007 at 10:39:12PM -0400, Greg Smith wrote:
There's a couple of potential to-do list ideas that build on the changes
in this area in 8.3:
I think that's the right way to go. It's too bad that this may still
happen in 8.3, but we're way past the point that this is a bug fix,
Am Freitag, 17. August 2007 schrieb Peter Eisentraut:
I'm having trouble with the hardcoded 60 second timeout in pg_ctl. pg_ctl
sometimes just times out and there is no way to make it wait a little
longer. I would like to add an option to be able to change that, say
pg_ctl -w --timeout=120.
On Mon, 2007-10-29 at 09:56 -0500, Kevin Grittner wrote:
Here's our script:
Thanks, I think that is better than what I'm doing.
One minor thing: I think it's still dependent on locale though, because
the output of pg_controldata is locale-dependent, right? It would work
fine for me, but it
On Mon, Oct 29, 2007 at 11:50 AM, in message
[EMAIL PROTECTED], Jeff Davis [EMAIL PROTECTED]
wrote:
Also, did you publish your pg_clearxlogtail program anywhere? I think
that would be helpful to many people, but I don't see it on pgfoundry.
So far I've just included with the email on the
On Mon, 2007-10-29 at 14:20 -0400, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
One minor thing: I think it's still dependent on locale though, because
the output of pg_controldata is locale-dependent, right? It would work
fine for me, but it would be nice if there was something
Or ... ask the application not the OS
psql select version() ;
Cheers
Medi
On 10/29/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
Leaving aside the question of why one might want to do this, Unix 101
should show you many ways to do it. For example,
sed -n -e 's/.*PG_VERSION /PG_VERSION
Jeff Davis [EMAIL PROTECTED] writes:
One minor thing: I think it's still dependent on locale though, because
the output of pg_controldata is locale-dependent, right? It would work
fine for me, but it would be nice if there was something that could be
released that anyone could use, including
Bruce Momjian wrote:
How about an environment variable to control the timeout? Is that
cleaner?
I don't see why it should be. I think Peter's --timeout suggestion
should be just fine.
cheers
andrtew
---(end of broadcast)---
TIP 4:
Peter Eisentraut [EMAIL PROTECTED] writes:
Somehow, the 60 second timeout seems completely arbitrary anyway. Maybe we
should remove it altogether. We could add an option as described above, but
then the packager who creates the init script or whoever creates the initial
configuration will
Andrew Dunstan [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
How about an environment variable to control the timeout? Is that
cleaner?
I don't see why it should be. I think Peter's --timeout suggestion
should be just fine.
I wrote a moment ago that the user can hit control-C when he
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the mythical pg_ping utility should be written. It seems the
easiest way out of the problem.
If pg_ctl were still a shell script there would be some point in that,
but since it's a C program it can certainly do anything a separate
utility would
On Mon, 2007-10-29 at 17:34 -0300, Alvaro Herrera wrote:
Maybe hack the postmaster to have a new special connection mode which
keeps the connection open until the startup process exits, to avoid
polling continuously (ideally report progress too, if at all
possible).
That sounds good to me.
Peter Eisentraut wrote:
Am Freitag, 17. August 2007 schrieb Peter Eisentraut:
I'm having trouble with the hardcoded 60 second timeout in pg_ctl. pg_ctl
sometimes just times out and there is no way to make it wait a little
longer. I would like to add an option to be able to change that, say
Peter Eisentraut wrote:
Am Freitag, 17. August 2007 schrieb Peter Eisentraut:
I'm having trouble with the hardcoded 60 second timeout in pg_ctl. pg_ctl
sometimes just times out and there is no way to make it wait a little
longer. I would like to add an option to be able to change that, say
Ühel kenal päeval, L, 2007-10-27 kell 14:10, kirjutas David Fetter:
On Sun, Oct 28, 2007 at 12:05:26AM +0300, Hannu Krosing wrote:
Ühel kenal päeval, L, 2007-10-27 kell 12:55, kirjutas Josh Berkus:
Merlin, Pavel,
Mutable session variables would be nice, but I'll take a plpgsql
--- Original Message ---
From: Peter Eisentraut [EMAIL PROTECTED]
To: pgsql-hackers@postgresql.org
Sent: 29/10/07, 17:54:00
Subject: Re: [HACKERS] pg_ctl configurable timeout
Am Freitag, 17. August 2007 schrieb Peter Eisentraut:
I'm having trouble with the hardcoded 60 second
Gregory Stark wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
What I was referring to, was a code cleanup of libpq several years
ago, when someone (maybe Bruce IIRC) removed ability to accept multiple
recordsets from backend altogether, on the basis that it is not used
anyway.
You can
Josh Berkus wrote:
Not only would they be generally useful for SP programming, but multisets
would eliminate one of the big hurdles in re-writing T-SQL stored
procedures in PG, and thus make it easier to port from SQL Server. You
don't hear a lot of demand for multisets on the mailing lists
Hannu Krosing [EMAIL PROTECTED] writes:
What I was referring to, was a code cleanup of libpq several years
ago, when someone (maybe Bruce IIRC) removed ability to accept multiple
recordsets from backend altogether, on the basis that it is not used
anyway.
You can still receive multiple
We've had two hard to diagnose errors in recovery in recent months. ISTM
that the core issue is the way we allow Resource Managers to have
multi-stage WAL actions that persist for long periods of time. This
means we have no way of telling whether the answer
rm_safe_restartpoint() == false is a
On Mon, Oct 29, 2007 at 07:32:11PM -0300, Alvaro Herrera wrote:
Gregory Stark wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
What I was referring to, was a code cleanup of libpq several
years ago, when someone (maybe Bruce IIRC) removed ability to
accept multiple recordsets from
Hi all,
Three years ago, Andrew MacRae logged the following bug:
http://archives.postgresql.org/pgsql-bugs/2004-02/msg00042.php
In brief, when installing on OS X with make install-strip,
installation goes fine, but initdb dies here:
creating conversions... ERROR: could not load library
Simon Riggs [EMAIL PROTECTED] writes:
What I'd like to do is force all of the RMs to record the lsn of any WAL
record that starts an incomplete action.
...
I'd like to suggest that those changes be performed now for 8.3 *and*
back-patched for 8.2.
There is zero chance of the former and less
Meredith L. Patterson [EMAIL PROTECTED] writes:
In brief, when installing on OS X with make install-strip,
installation goes fine, but initdb dies here:
...
I see three possible fixes:
1) Patch config/install-sh such that on OS X, install-strip calls 'strip
-x'. This removes local symbols
40 matches
Mail list logo
