Horton

Re: Something is wrong with wal_compression

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, Laurenz Albe <laurenz.albe@cybertec.at>, Thomas Munro <thomas.munro@gmail.com>, Andrey Borodin <amborodin86@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-01-28T03:49:17Z
Lists: pgsql-hackers 
Hi,

On 2023-01-27 22:39:56 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2023-01-28 11:38:50 +0900, Michael Paquier wrote:
> >> 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.
> 
> What are you using it for, that you don't care whether the answer
> is trustworthy?

It's quite commonly used as part of trigger based replication tools (IIRC
that's its origin), monitoring, as part of client side logging, as part of
snapshot management.

txid_current() predates pg_xact_status() by well over 10 years. Clearly we had
lots of uses for it before pg_xact_status() was around.

Greetings,

Andres Freund

Commits

  1. Remove recovery test 011_crash_recovery.pl

  2. Add a txid_status function.