On Fri, 2010-04-30 at 11:50 -0400, Tom Lane wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> > Eliminating null columns and mangling column headers for length, I
> > get this:
>
> > locktype | tranid | virtualx | pid | mode | gr
> > transactionid | 39773877 | 63/15761 | 11157 | ShareLock | f
> > transactionid | 39773877 | 4/10902 | 6421 | ExclusiveLock | t
>
> > So it looks like two locks on the same transaction ID by different
> > transactions. How does that happen?
...
> As Peter stated, there's no evidence of an actual problem in this
> bug report. I'd go looking for clients sitting with open
> transactions...
>
> regards, tom lane
Well, I don't have the pg_stats_activity output at hand, but there was
no other long-running transaction at the time.
I just witnessed it happen again, I've had this problem (undetected
deadlocks) happen before, but not nearly as often. Could it be some form
of database corruption?
(I'll issue a REINDEX just in case, as soon as there's an open window).
Even if it is indeed database corruption this time, I've had it happen
before.
I guess I'll have to work on a script that reproduces this behavior.
Anyway, I'd suggest you don't dismiss this bug report so lightly. I know
it doesn't look like a deadlock from where you're standing, but it does
so from where I am. It behaves like one. If there's any diagnostic input
I can provide to help you track it down, I'll be glad to - just bear in
mind that this is hard for me to reproduce, and since I'm in a
production environment, recompiling and tinkering with the postgresql
cluster would be... undesirable.