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(at)decibel(dot)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(at)decibel(dot)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?"