Tom Lane wrote:
It's the oldest xmin of any transaction that's local to your database,
but those xmin values themselves were computed globally --- so what
matters is the oldest transaction that was running when any local
transaction started. In this case I expect it's the VACUUM's own
transaction
I had written:
[snip]
The problem is that attempts to vacuum these tables resulted in NNN
dead row versions cannot be removed yet. Went through a lot of
analysis (e.g.: Any hanging txns?) and trying different things with
folks on the #PostgreSQL IRC channel, all to no avail.
[snip]
Okay,
On Fri, Apr 02, 2004 at 12:02:22PM -0500, Jim Seymour wrote:
[...]
Which is all well-and-good (tho, my ignorance readily conceded, four
minutes seems a mite... long), *except*: If I shut-down the
WebObjects application which, again, never accesses the db in
question, much-less any of its
On Fri, Apr 02, 2004 at 12:02:22PM -0500, Jim Seymour wrote:
[...]
Which is all well-and-good (tho, my ignorance readily conceded, four
minutes seems a mite... long), *except*: If I shut-down the
WebObjects application which, again, never accesses the db in
question, much-less any
On Fri, Apr 02, 2004 at 02:51:30PM -0500, Jim Seymour wrote:
On Fri, Apr 02, 2004 at 12:02:22PM -0500, Jim Seymour wrote:
Ok, so the WebObjects app keeps an idle open transaction? (i.e. it
issues a BEGIN as soon as the previous transaction is finished.) I'm not
sure I read the code
Alvaro Herrera [EMAIL PROTECTED] wrote:
[snip]
Turn on query logging and see if the BEGIN is issued right after the
COMMIT/ROLLBACK, or whether it waits and issues it right before
SELECT/CREATE TEMP TABLE.
It doesn't matter if it's only doing queries; if it does them inside a
[EMAIL PROTECTED] (Jim Seymour) writes:
Again the difference: With WebObjects running, deleting rows and
trying to vacuum immediately, even full, fails. Shut-down WebObjects
and I can.
WebObjects is evidently holding an open transaction. Ergo, anything
deleted after the start of that
Tom Lane [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Jim Seymour) writes:
Again the difference: With WebObjects running, deleting rows and
trying to vacuum immediately, even full, fails. Shut-down WebObjects
and I can.
WebObjects is evidently holding an open transaction. Ergo,
[EMAIL PROTECTED] (Jim Seymour) writes:
Tom Lane [EMAIL PROTECTED] wrote:
WebObjects is evidently holding an open transaction.
It certainly isn't holding open a transaction in the database I'm
working with.
Which database the transaction is in isn't real relevant... the logic is
done
On Fri, Apr 02, 2004 at 07:35:20PM -0500, Tom Lane wrote:
[EMAIL PROTECTED] (Jim Seymour) writes:
Again the difference: With WebObjects running, deleting rows and
trying to vacuum immediately, even full, fails. Shut-down WebObjects
and I can.
WebObjects is evidently holding an open
On Fri, 2 Apr 2004, Alvaro Herrera wrote:
On Fri, Apr 02, 2004 at 07:35:20PM -0500, Tom Lane wrote:
[EMAIL PROTECTED] (Jim Seymour) writes:
Again the difference: With WebObjects running, deleting rows and
trying to vacuum immediately, even full, fails. Shut-down WebObjects
and I
Tom Lane [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Jim Seymour) writes:
Tom Lane [EMAIL PROTECTED] wrote:
WebObjects is evidently holding an open transaction.
It certainly isn't holding open a transaction in the database I'm
working with.
Which database the transaction is in
Alvaro Herrera [EMAIL PROTECTED] writes:
But, if I read the code correctly, the oldest xmin vacuum cares about
for a non-shared relation should be local to the database, shouldn't it?
It's the oldest xmin of any transaction that's local to your database,
but those xmin values themselves were
[EMAIL PROTECTED] (Jim Seymour) writes:
But I see entries like that if I just *start* *up* psql, without
doing anything:
Sure. You are doing something when you execute select from
pg_locks ... that command executes inside a transaction, just
like any other Postgres operation. The problem
Hi,
[Just so y'all know: This has been discussed extensively in
#PostgreSQL and I tried asking the question in both -admin and
-general, first. Also did some web searching.]
Environment:
PostgreSQL 7.4.2
Locally built with GCC 3.3.1
Solaris 8 (Sparc)
I have a relatively simple
15 matches
Mail list logo
