Re: Something is wrong with wal_compression - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Something is wrong with wal_compression
Date
Msg-id Y9SKuootyLVoJDid@paquier.xyz
Whole thread Raw
In response to Re: Something is wrong with wal_compression  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: Something is wrong with wal_compression
List pgsql-hackers
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.

FWIW, my vote goes for a more expensive but reliable function even in
stable branches.  Even 857ee8e mentions that this could be used on a
lost connection, so we don't even satisfy the use case of the original
commit as things stand (right?), because lost connection could just be
a result of a crash, and if crash recovery reassigns the XID, then the
client gets it wrong.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Small omission in type_sanity.sql
Next
From: Andres Freund
Date:
Subject: Re: Add n_tup_newpage_upd to pg_stat table views