MIME-Version: 1.0
References: 
 <CAKU4AWqF=FgsnyjSorBKLeCi50iB7NmT4KaQWKmp-gCgKmd_uQ@mail.gmail.com>
 <CADK3HH+F6AxVp-Z0qtiK8sc1vC7ekuprria_kzTcUg0yBfGzrA@mail.gmail.com>
In-Reply-To: 
 <CADK3HH+F6AxVp-Z0qtiK8sc1vC7ekuprria_kzTcUg0yBfGzrA@mail.gmail.com>
From: Andy Fan <zhihui.fan1213@gmail.com>
Date: Wed, 7 Dec 2022 11:12:40 +0800
Message-ID: 
 <CAKU4AWrS71pUTc1h7v3Rb45uvF7T2JCYHBOSgLLCgWBOyRsD4g@mail.gmail.com>
Subject: Re: Would preparing internally during XAResource.end(xid,
 TMSUCCESS) works?
To: Dave Cramer <davecramer@gmail.com>
Cc: pgsql-jdbc@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000bf0e6905ef344b6f"
Archived-At: 
 <https://www.postgresql.org/message-id/CAKU4AWrS71pUTc1h7v3Rb45uvF7T2JCYHBOSgLLCgWBOyRsD4g%40mail.gmail.com>
Precedence: bulk

--000000000000bf0e6905ef344b6f
Content-Type: text/plain; charset="UTF-8"

Hi Dave:

Thanks for your feedback and sorry for the late reply.

Hi Andy,
>
> Sorry I'm not much help here.
>
> Were you able to figure this out?
>
>
I've been working on this for a while.  It would not work per
current  PG server code.  The biggest issue is when user
calls 'xa_end',   he/she isn't intent to persist the 2pc
transaction, but the PG code would do that during the 'prepare
transaction' statement.  In this case WE SHOULD NOT recover
it again during crash recovery.   I'm hacking the pg server code
not do it until a user called 'xa_prepare'.

The internal way to do this is: during xa_end,  I run the 'prepare
transaction xxx' statement and record a new xlog to rollback it
2pc, this is done at the end of the crash recovery stage.   and
If the user runs the 'xa_prepare',  I would add another xlog to
let the above thing not happen at the end of the crash recovery
stage.

(I hacked both JDBC driver and server code for the above stuff)

Besides this, I also find another issue that

connection 1:
xa_start('foo', ..);
insert into t select 1;
xa_end('foo', ..);

connection 2:
xa_start('foo', ..);
select * from t;  ==>  The above insert from connection 1 is visible for
current connection, but in our JDBC it doesn't.

I am also hacking this case as well, just record the transaction xid
which the 'foo' belongs to and add a new rule to the MVCC to let
the tuple be visible as well.

still tuned and testing now.

-- 
Best Regards
Andy Fan

--000000000000bf0e6905ef344b6f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi=C2=A0Dave:</div><div><br></div><div>Thanks for you=
r feedback and sorry for the late reply.</div><div><br></div><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr"><div dir=3D"ltr">Hi=C2=A0Andy,<div><br></div><div>Sorry I&#39;m not mu=
ch help here.</div><div><br></div><div>Were you able to figure this out?</d=
iv><div><div><div dir=3D"ltr"><br></div></div></div></div></div></blockquot=
e><div><br></div><div>I&#39;ve been working on this for a while.=C2=A0 It w=
ould not work per</div><div>current=C2=A0 PG server code.=C2=A0 The biggest=
 issue is when user=C2=A0</div><div>calls &#39;xa_end&#39;,=C2=A0 =C2=A0he/=
she isn&#39;t intent to persist the 2pc</div><div>transaction, but the PG c=
ode would do that during the &#39;prepare</div><div>transaction&#39; statem=
ent.=C2=A0 In this case WE SHOULD NOT recover</div><div>it again during cra=
sh recovery.=C2=A0 =C2=A0I&#39;m hacking the pg server code=C2=A0</div><div=
>not do it until a user called &#39;xa_prepare&#39;.</div><div><br></div><d=
iv>The internal way to do this is: during xa_end,=C2=A0 I run the &#39;prep=
are</div><div>transaction xxx&#39; statement and record a new xlog to rollb=
ack it</div><div>2pc, this is done at the end of the crash recovery stage.=
=C2=A0 =C2=A0and=C2=A0</div><div>If the user runs the &#39;xa_prepare&#39;,=
=C2=A0 I would add another xlog to=C2=A0</div><div>let the above thing not =
happen at the end of the crash recovery</div><div>stage.=C2=A0</div><div><b=
r></div><div>(I hacked both JDBC driver and server code for the above stuff=
)</div><div><br></div><div>Besides this, I also find another issue that</di=
v><div><br></div><div>connection 1:</div><div>xa_start(&#39;foo&#39;, ..);<=
/div><div>insert into t select 1;</div><div>xa_end(&#39;foo&#39;, ..);</div=
><div><br></div><div>connection 2:</div><div>xa_start(&#39;foo&#39;, ..);</=
div><div>select * from t;=C2=A0 =3D=3D&gt;=C2=A0 The above insert from conn=
ection 1 is visible for</div><div>current connection, but in our JDBC it do=
esn&#39;t.=C2=A0</div><div><br></div><div>I am also hacking this case as we=
ll, just record the transaction xid=C2=A0</div><div>which the &#39;foo&#39;=
 belongs to and add a new rule to the MVCC to let</div><div>the tuple be vi=
sible as well.=C2=A0</div><div><br></div><div>still tuned and testing now.<=
/div></div><div><br></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature"=
><div dir=3D"ltr">Best Regards<div>Andy Fan</div></div></div></div>

--000000000000bf0e6905ef344b6f--