标签
PostgreSQL , 10.0 , 2PC , txid_status , unknown事务
背景
在一些极端情况下，例如当客户端发出事务提交SQL后，客户端收到数据库返回的提交状态前，如果客户端崩溃或数据库异常，导致客户端不知道事务的最终状态到底是提交成功还是失败的。
那么怎么解决这个问题呢？
1. 一种方法是走2PC协议，先使用预提交，然后在发出commit 之前的预提交。（因为只要预提交成功，就可以认为后面的commit是一定可以成功的），从而来避免unknown的事务问题。
但是2PC引入了性能的问题，因为需要和数据库交互多次。
2. 10.0引入一个新的功能，查看以往的事务提交状态。在发生崩溃问题后，应用程序再起来之后，可以通过事务号，查到事务的提交状态。杜绝unknown的事务。
为了查询事务状态，应用程序必须要保留事务号，目前PostgreSQL通过txid_current()可以查询当前的事务号，结合insert ,update,... returning txid_current()，可以在一次交互中得到这个事务号。从避免因为这个功能引入的增加一次交互。
未来PostgreSQL可能会在驱动层面解决这个问题，减少业务程序的开发工作量（使用txid_current()获得事务号）。
Issuing a “multi-statement query”,
e.g. INSERT INTO ...; SELECT txid_current(); if it doesn’t need the result of the prior query;
Combining it with another query,
e.g. INSERT INTO ... RETURNING txid_current();
Using client driver support for batching queries to dispatch the txid_current() query along with other queries without waiting for a reply for each query.
In a future version PostgreSQL may automatically report the transaction ID when it is assigned to make this easier for applications.
例子
SELECT txid_status(BIGINT '63204');
txid_status的参数是xid, 即txid_current()的返回值类型。
注意不是int32, 是int64哦。
patch如下
Add a txid_status function.
author Robert Haas <rhaas@postgresql.org>
Sat, 25 Mar 2017 00:00:53 +0800 (12:00 -0400)
committer Robert Haas <rhaas@postgresql.org>
Sat, 25 Mar 2017 00:00:53 +0800 (12:00 -0400)
commit 857ee8e391ff6654ef9dcc5dd8b658d7709d0a3c
tree 1d0f54ef032aa0a90bcda70e86ee3850167462ad tree | snapshot
parent 42b4b0b2413b9b472aaf2112a3bbfd80a6ab4dc5 commit | diff
Add a txid_status function.
If your connection to the database server is lost while a COMMIT is
in progress, it may be difficult to figure out whether the COMMIT was
successful or not. This function will tell you, provided that you
don't wait too long to ask. It may be useful in other situations,
too.
Craig Ringer, reviewed by Simon Riggs and by me
Discussion: http://postgr.es/m/CAMsr+YHQiWNEi0daCTboS40T+V5s_+dst3PYv_8v2wNVH+Xx4g@mail.gmail.com
这个patch的讨论，详见邮件组，本文末尾URL。
PostgreSQL社区的作风非常严谨，一个patch可能在邮件组中讨论几个月甚至几年，根据大家的意见反复的修正，patch合并到master已经非常成熟，所以PostgreSQL的稳定性也是远近闻名的。
参考
https://blog.2ndquadrant.com/traceable-commit-postgresql-10/
