There was a bug in 7.1.2 that was fixed in 7.1.3 that may be back in
7.2.
I downloaded 7.2 yesterday morning and started testing it. I left some
procedures running overnight performing random updates in a table.
Looking at task manager this morning, the three backend processes are
each consuming
Tom ([EMAIL PROTECTED]) reports a bug with a severity of 1
The lower the number the more severe it is.
Short Description
fails to make darwin 5.2
Long Description
pasting output from configure and make:
[localhost:/postgresql-7.1.3] tom% ./configure | tee myconfig.log
loading cache ./config.cac
"Tom Pfau" <[EMAIL PROTECTED]> writes:
> There was a bug in 7.1.2 that was fixed in 7.1.3 that may be back in
> 7.2.
> I downloaded 7.2 yesterday morning and started testing it. I left some
> procedures running overnight performing random updates in a table.
> Looking at task manager this morning
[EMAIL PROTECTED] writes:
> /usr/bin/ld: -undefined error must be used when -twolevel_namespace is in effect
This is dealt with in PG 7.2.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archive
There was a cygwin postgresql 7.1.3-2 release to fix a file handle problem
(init_rels() not closing pg_internal.init):
http://archives.postgresql.org/pgsql-cygwin/2002-01/msg00034.php
which refers to:
http://archives.postgresql.org/pgsql-cygwin/2002-01/msg00029.php
Maybe this is it?
- Stuart
> --
"Henshall, Stuart - WCP" <[EMAIL PROTECTED]> writes:
> There was a cygwin postgresql 7.1.3-2 release to fix a file handle problem
> (init_rels() not closing pg_internal.init):
> Maybe this is it?
No, because (a) that problem is also fixed in 7.2, and (b) that was
only responsible for leaking one
No, that was a different problem related to recreating the
pg_internal.init file after a vacuum. This current leakage occurs
during normal usage.
-Original Message-
From: Henshall, Stuart - WCP
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 05, 2002 11:49 AM
To: 'Tom Lane'; Tom Pfau
We were initially using 7.1.2. Some overnight tests of our application
revealed that the backends were not releasing handles according to task
manager. We upgraded to 7.1.3 and the problem went away.
My initial testing of 7.2 shows the same symptom although I don't know
that it's the same cause
Running postgresql 7.1.3:
I have a timestamp column in my table and I want to select all rows either
elder or newer than 14 days.
SELECT * FROM table WHERE column > CURRENT_TIMESTAMP-'14 days'::interval
SELECT * FROM table WHERE column < CURRENT_TIMESTAMP-'14 days'::interval
Postgresql refuses to
"Tom Pfau" <[EMAIL PROTECTED]> writes:
> In any case, if I run my test procedure which just performs updates to a
> random column of a random row of a 1000 row table, I can watch the
> handle usage continue to rise on the backend process.
> Looking a bit more closely now, a single process doesn't
I'm attaching two sql scripts in a zip file. Run script1.sql from one
session. After it's done with the inserts, start script2.sql in another
session. Have task manager running in the background and watch the
backends eat handles.
If these don't run long enough, cut and paste some more updates
11 matches
Mail list logo
