On Fri, 2010-04-30 at 11:50 -0400, Tom Lane wrote: > "Kevin Grittner" <kevin.gritt...@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.
