Ryan Johnson <ryan.johnson@xxxxxxxxxxxxxx> wrote: > what factors might cause a prepared transaction to exist in the > first place? As part of a "distributed transaction" using "two phase commit" a PREPARE TRANSACTION statement would have had to run against PostgreSQL: http://www.postgresql.org/docs/current/interactive/sql-prepare-transaction.html > I'm running a single-node db, and I've had only normal database > shutdowns, so I wouldn't have expected any. Prepared transactions survive shutdowns, normal or not, so that doesn't matter; but prepared transactions are normally used with a transaction manager coordinating transactions among multiple data stores. On the other hand, I have seen cases where a developer "playing around" with database features has created one. And using them with a "home-grown" transaction manager rather than a mature product is risky; there are some non-obvious pitfalls to avoid. Anyway, you may have found a bug, but most of what you're seeing could be caused by a prepared transaction sitting around indefinitely, so it's something to check before looking at other possible causes. If you have a way to reproduce this from a new cluster, please share it. That always makes diagnosis much easier. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
