On Fri, Apr 1, 2011 at 1:00 PM, Dan Ports d...@csail.mit.edu wrote:
While looking into a SSI bug, I noticed that we don't actually display
the pid of the holding transaction, even though we have that
information available.
The attached patch fixes that.
Committed.
--
Robert Haas
While looking into a SSI bug, I noticed that we don't actually display
the pid of the holding transaction, even though we have that
information available.
The attached patch fixes that.
One note is that it will show the pid of the backend that executed the
transaction, even if that transaction
Dan Ports d...@csail.mit.edu wrote:
While looking into a SSI bug, I noticed that we don't actually
display the pid of the holding transaction, even though we have
that information available.
I thought we already had that, but clearly I was mistaken.
The attached patch fixes that.
One
On Fri, Apr 01, 2011 at 12:20:25PM -0500, Kevin Grittner wrote:
I thought we already had that, but clearly I was mistaken.
Yeah, so did I. Turns out we had the vxid but not the pid. IIRC, we
weren't tracking a SERIALIZABLEXACT's pid yet, at the time we wrote the
code for pg_locks.
I guess the
Dan Ports d...@csail.mit.edu wrote:
There's no urgent need to have this, although it's obviously more
correct than the current behavior. It might be useful for
debugging.
Agreed all around. For the benefit of the more casual follower of
the thread, attached is a simple example of the
On Fri, 2011-04-01 at 13:00 -0400, Dan Ports wrote:
While looking into a SSI bug, I noticed that we don't actually display
the pid of the holding transaction, even though we have that
information available.
Is there a chance that the PID will reference a backend that has either
terminated or
Jeff Davis pg...@j-davis.com wrote:
On Fri, 2011-04-01 at 13:00 -0400, Dan Ports wrote:
While looking into a SSI bug, I noticed that we don't actually
display the pid of the holding transaction, even though we have
that information available.
Is there a chance that the PID will reference a
