Re: Something is wrong with wal_compression
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Andrey Borodin <amborodin86@gmail.com>,
Justin Pryzby <pryzby@telsasoft.com>,
pgsql-hackers@lists.postgresql.org,
Michael Paquier <michael@paquier.xyz>
Date: 2023-01-26T23:04:42Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > On Fri, Jan 27, 2023 at 11:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> If any tuples made by that transaction had reached disk, >> we'd have a problem. > The problem is that the WAL wasn't flushed, allowing the same xid to > be allocated again after crash recovery. But for any data pages to > hit the disk, we'd have to flush WAL first, so then it couldn't > happen, no? Ah, now I get the point: the "committed xact" seen after restart isn't the same one as we saw before the crash, but a new one that was given the same XID because nothing about the old one had made it to disk yet. > FWIW I also re-complained about the dangers of anyone > relying on pg_xact_status() for its stated purpose after seeing > tanager's failure[1]. Indeed, it seems like this behavior makes pg_xact_status() basically useless as things stand. regards, tom lane
Commits
-
Remove recovery test 011_crash_recovery.pl
- 403d82dd54b5 11.19 landed
- e8fb2a721b36 12.14 landed
- ee11824ac4c2 13.10 landed
- 96d42bd27fef 14.7 landed
- c5b2975ec183 15.2 landed
- 8c1cd726c5d9 16.0 landed
-
Add a txid_status function.
- 857ee8e391ff 10.0 cited