Re: commiting transaction from outside - Mailing list pgsql-admin

From Julius Tuskenis
Subject Re: commiting transaction from outside
Date
Msg-id 4E89FC2D.2050406@nsoft.lt
Whole thread Raw
In response to Re: commiting transaction from outside  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-admin
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


pgsql-admin by date:

Previous
From: Kevin Ricords
Date:
Subject: index bloat on partial index 8.4
Next
From: Scott Ribe
Date:
Subject: Re: commiting transaction from outside