thread-index: Acb/HxYYdagZ+qruQRSDIJps3Wfprw==
Subject: Re: "recovering prepared transaction" after serverrestart message
From: "Simon Riggs" <simon@2ndquadrant.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Content-class: urn:content-classes:message
Importance: normal
Cc: <joe@mcknight.de>,
	<pgsql-hackers@postgresql.org>
In-Reply-To: <27067.1162536485@sss.pgh.pa.us>
References: <e3b306b71615a24e1be5e713ad3df048@>
	<27067.1162536485@sss.pgh.pa.us>
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 03 Nov 2006 08:06:55 +0000
Message-ID: <1162541215.3587.507.camel@silverbirch.site>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

On Fri, 2006-11-03 at 01:48 -0500, Tom Lane wrote:

> I agree that there's a usability issue here though; I've been burnt by
> forgotten prepared xacts myself (eg by control-C'ing pg_regress at just
> the wrong time).  Would it help if we included prepared xacts in the
> pg_stat_activity view?  
> Is there any other place we could make them
> more visible during normal server operation?

We only care when they break, otherwise its just situation normal, yes?

Is there a way to see prepared transactions where the original session
that prepared then has died? Perhaps the message at startup should be
"you have at least one prepared transaction that needs resolution". We
need something at that point, otherwise a PITR recovery is fairly likely
to contain them and we need to know that.

Otherwise on a system using prepared transactions heavily you may not
spot the odd or two that have crashed and need resolution. Presumably
they will effect oldestxmin, so its fairly important to be able to
resolve them in a timely manner or at least know they are there.

Not that I am advising their use though....

-- 
  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com