Re: Something is wrong with wal_compression

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Thomas Munro <thomas.munro@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andrey Borodin <amborodin86@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-01-28T02:38:50Z
Lists: 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

Commits

  1. Remove recovery test 011_crash_recovery.pl

  2. Add a txid_status function.