Ways to check the status of a long-running transaction

Started by Jim C. Nasbyalmost 21 years ago3 messages
#1Jim C. Nasby
decibel@decibel.org

I recall this being discussed before, but I couldn't manage to find it
in the archives.

Is there any way to see how many rows a running transaction has written?
vacuum analyze verbose only reports visible rows.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

#2Greg Stark
gsstark@mit.edu
In reply to: Jim C. Nasby (#1)
Re: Ways to check the status of a long-running transaction

"Jim C. Nasby" <decibel@decibel.org> writes:

I recall this being discussed before, but I couldn't manage to find it
in the archives.

Is there any way to see how many rows a running transaction has written?
vacuum analyze verbose only reports visible rows.

Not AFAIK. In the past I've done ls -l and then divided by the average row
size. But that required some guesswork and depended on the fact that I was
building the table from scratch.

I think there's a tool to dump the raw table data which might be handy if you
know the table didn't have a lot of dead tuples in it.

It would be *really* handy to have a working dirty read isolation level that
allowed other sessions to read uncommitted data.

--
greg

#3Jim C. Nasby
decibel@decibel.org
In reply to: Greg Stark (#2)
Re: [GENERAL] Ways to check the status of a long-running transaction

Moving to hackers...

On Wed, Jan 19, 2005 at 11:57:12PM -0500, Greg Stark wrote:

"Jim C. Nasby" <decibel@decibel.org> writes:

I recall this being discussed before, but I couldn't manage to find it
in the archives.

Is there any way to see how many rows a running transaction has written?
vacuum analyze verbose only reports visible rows.

Not AFAIK. In the past I've done ls -l and then divided by the average row
size. But that required some guesswork and depended on the fact that I was
building the table from scratch.

Unfortunately in this case I'm not. And I wish I had some way to see
what was going on, because I let this process run for 2 days, then
canceled and restarted it and it ran in 5 minutes. It was consuming CPU
the whole time, too; I wish I knew what the hell it was doing.

I think there's a tool to dump the raw table data which might be handy if you
know the table didn't have a lot of dead tuples in it.

It would be *really* handy to have a working dirty read isolation level that
allowed other sessions to read uncommitted data.

I can see arguments against this. I'd be happy just having a means to
see how many new (not-yet-visible) tuples there were. Or better yet, how
many tuples had been modified by a specific transaction (since it could
both be inserting and deleting).

Can one or the other options be added as a TODO?
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"