On Fri, Jan 27, 2023 at 3:04 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.mu...@gmail.com> writes: > > On Fri, Jan 27, 2023 at 1:30 PM Michael Paquier <mich...@paquier.xyz> wrote: > >> My opinion would be to make this function more reliable, FWIW, even if > >> that involves a performance impact when called in a close loop by > >> forcing more WAL flushes to ensure its report durability and > >> consistency. > > > Yeah, the other thread has a patch for that. But it would hurt some > > workloads. > > I think we need to get the thing correct first and worry about > performance later. What's wrong with simply making pg_xact_status > write and flush a record of the XID's existence before returning it? > Yeah, it will cost you if you use that function, but not if you don't.
It would be pg_current_xact_id() that would have to pay the cost of the WAL flush, not pg_xact_status() itself, but yeah that's what the patch does (with some optimisations). I guess one question is whether there are any other reasonable real world uses of pg_current_xact_id(), other than the original goal[1]. If not, then at least you are penalising the right users, even though they probably only actually call pg_current_status() in extremely rare circumstances (if COMMIT hangs up). But I wouldn't be surprised if people have found other reasons to be interested in xid observability, related to distributed transactions and snapshots and suchlike. There is no doubt that the current situation is unacceptable, though, so maybe we really should just do it and make a faster one later. Anyone else want to vote on this? [1] https://www.postgresql.org/message-id/flat/CAMsr%2BYHQiWNEi0daCTboS40T%2BV5s_%2Bdst3PYv_8v2wNVH%2BXx4g%40mail.gmail.com
