On Mon, Apr 4, 2011 at 2:50 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
>> Dan Ports <drkp@csail.mit.edu> wrote:
>>> I see Robert committed that one already. If there's a consensus
>>> that omitting the pid for committed transactions is the right
>>> thing to do, I'm happy to put together a patch. I think that is a
>>> better approach than trying to keep it after commit until the
>>> connection closes, but all of this is sufficiently minor that
>>> it's probably not worth worrying much about.
>>
>> I couldn't really figure out why that would be better, but if
>> there's a reason I'm fine with it.
>
> If people think that showing the pid which created the lock after
> the process has terminated is confusing, the reason I would lean
> toward not showing it after transaction completion is that we can
> check a bit-flag field which is already in front of us rather than
> making calls out to other code for each lock, which might get
> expensive, and perhaps compromise modularity.
Well, the flip side is that if you have appropriate logging turned on,
you might be able to go back and look at what the transaction that
took the lock actually did, which won't be possible if you arbitrarily
throw the PID away.
I'm not going to lose any sleep about this one whatever we decide, but
my gut is that we have more important things to tinker with.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company