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