Re: SSI slows down over time

Ryan Johnson <ryan(dot)johnson(at)cs(dot)utoronto(dot)ca> 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