Kyotaro Horiguchi <horikyota....@gmail.com> writes:
> I noticed that 011_crash_recovery.pl intermittently (that being said,
> one out of three or so on my environment) fails in the second test.
Hmmm ... what environment is that? This test script hasn't changed
meaningfully in several years, and we have not seen any real issues
with it up to now.
> If the server crashed before emitting WAL records for the transaction
> just started, the restarted server cannot know the xid is even
> started. I'm not sure that is the intention of the test but we must
> make sure the WAL to be emitted before crashing. CHECKPOINT ensures
> that.
The original commit for this test says
----
commit 857ee8e391ff6654ef9dcc5dd8b658d7709d0a3c
Author: Robert Haas <rh...@postgresql.org>
Date: Fri Mar 24 12:00:53 2017 -0400
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+x...@mail.gmail.com
----
If the function needs a CHECKPOINT to give a reliable answer,
is it actually good for the claimed purpose?
Independently of that, I doubt that adding a checkpoint call
after the pg_current_xact_id() call is going to help. The
Perl script is able to move on as soon as it's read the
function result. If we need this hack, it has to be put
before that SELECT, AFAICS.
regards, tom lane
