DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ymail.com;
 h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
 b=nOrfcePC8QJBbOuUU6sF0Bey6PoXTmZnqgZSR5CBSwnaKfPLdjv4D6Fv325dNHqCaExncm3YXtfog7xD54LWRpmYE5uysDVASbQAT5NyNB6xkG8juc72xYAvEukTZyKdKqxxJ58G1sZiueSQR8Ng1EdlHg2h5qNe1i00A8HqPII=;
Message-ID: <1397490843.97407.YahooMailBasic@web122304.mail.ne1.yahoo.com>
Date: Mon, 14 Apr 2014 08:54:03 -0700 (PDT)
From: Kevin Grittner <kgrittn@ymail.com>
Subject: Re: SSI slows down over time
To: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
Cc: pgsql-performance@postgresql.org
In-Reply-To: <534BEF32.9060309@cs.utoronto.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Ryan Johnson <ryan.johnson@cs.utoronto.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


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance