Hi,
On 2023-01-28 11:38:50 +0900, Michael Paquier wrote:
> On Fri, Jan 27, 2023 at 06:06:05AM +0100, Laurenz Albe wrote:
> > On Fri, 2023-01-27 at 16:15 +1300, Thomas Munro wrote:
> >> 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?
> >
> > I wasn't aware of the existence of pg_xact_status, so I suspect that it
> > is not a widely known and used feature. After reading the documentation,
> > I'd say that anybody who uses it will want it to give a reliable answer.
> > So I'd agree that it is better to make it more expensive, but live up to
> > its promise.
> A code search within the Debian packages (codesearch.debian.net) and
> github does not show that it is not actually used, pg_xact_status() is
> reported as parts of copies of the Postgres code in the regression
> tests.
Not finding a user at codesearch.debian.net provides useful information for C
APIs, but a negative result for an SQL exposed function doesn't provide any
information. Those callers will largely be in application code, which largely
won't be in debian.
And as noted two messages up, we wouldn't need to flush in pg_xact_status(),
we'd need to flush in pg_current_xact_id()/txid_current().
> FWIW, my vote goes for a more expensive but reliable function even in
> stable branches.
I very strenuously object. If we make txid_current() (by way of
pg_current_xact_id()) flush WAL, we'll cause outages.
Greetings,
Andres Freund
