Hash: SHA1

> Sounds like a deadlock waiting to happen :-(

Yeah, this sounds more and more like a job for a client application.

> AFAIK the general practice is to just accept the fact that vacuum can't
> remove recently-dead tuples.  You should look into whether you can't
> shorten your transactions --- very-long-running transactions create
> other performance issues besides vacuum not removing stuff.

Sure, but does a long-running transaction on a different database in
the same cluster have any other consequences?

At any rate, I suppose this is something I can probably code around. If it
gets too bad, I'll try to coordinate the timing a bit more between the
databases, increase the frequency of vacuum, or simply kill some of the
long-running transactions before kicking off the vacuum.

Brian Hurt wrote:
> My understanding is that vacuum can not delete any row that was deleted
> after the oldest outstanding transaction. [snip]

Thanks, that was a good explanation.

> Which is why having only a single transaction open, but it's been open
> for 24 hours, is a problem.

Well, 24 hours is a bit much :), but perhaps until a database-specific xmin
is enabled, I'll also consider using an entirely different cluster for
databases which do long-runnning queries.

- --
Greg Sabino Mullane [EMAIL PROTECTED]
End Point Corporation
PGP Key: 0x14964AC8 200612181419


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to