Message-ID: <4E89FC2D.2050406@nsoft.lt>
Date: Mon, 03 Oct 2011 21:17:17 +0300
From: Julius Tuskenis <julius@nsoft.lt>
Organization: UAB nSoft
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: pgsql-admin@postgresql.org
Subject: Re: commiting transaction from outside
References: <4E89E7BF.9040009@nsoft.lt>
	<4E89B12F02000025000419BD@gw.wicourts.gov>
In-Reply-To: <4E89B12F02000025000419BD@gw.wicourts.gov>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2011.10.03 20:57, Kevin Grittner wrote:
>
>
> I can't think of any way to issue the commit, unless the application
> is running in an unusual environment which lets you break in and
> issue ad hoc commands on its connection.  There is a way you could
> fish out the effects of the transaction, although it might be a fair
> bit of work.  Each tuple inserted or updated has the transaction ID
> set as its xmin in the new tuple, and every tuple deleted or updated
> has the transaction ID set as its xmax.  The old and new are
> guaranteed not to go away until the transaction completes, one way
> or the other.  With some clever programming you could capture the
> net effect of the transaction, and duplicate that effect after the
> transaction is rolled back.
>
> Be aware that while the transaction is stuck "idle in transaction"
> the cleanup of old tuples can't proceed normally; so if you're
> continuing to modify any database in the cluster, it could be
> accumulating bloat until you resolve this.
>
> -Kevin
>
Thank You, Kevin, Julien, Scott for the help.

Scott - your idea is worth remembering. The problem is I can not see the 
tuples until they are committed, or can I ? And if I understand you 
correctly I can not rely on xmin and xmax values after the commit. 
Anyway Thank You for the Idea.

I solved the problem by using sql injection methods (I was lucky the 
application was buggy enough).

-- 
Julius Tuskenis
Programavimo skyriaus vadovas
UAB nSoft
mob. +37068233050