Horton

Re: Something is wrong with wal_compression

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrey Borodin <amborodin86@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>
Date: 2023-01-26T22:14:45Z
Lists: pgsql-hackers 
Andrey Borodin <amborodin86@gmail.com> writes:
> On Thu, Jan 26, 2023 at 12:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That test case is demonstrating fundamental
>> database corruption after a crash.

> Not exactly corruption. XID was not persisted and buffer data did not
> hit a disk. Database is in the correct state.

Really?  I don't see how this part is even a little bit okay:

[00:40:50.744](0.046s) not ok 3 - xid is aborted after crash
[00:40:50.745](0.001s) 
[00:40:50.745](0.000s) #   Failed test 'xid is aborted after crash'
#   at t/011_crash_recovery.pl line 57.
[00:40:50.746](0.001s) #          got: 'committed'
#     expected: 'aborted'

If any tuples made by that transaction had reached disk,
we'd have a problem.

			regards, tom lane

Commits

  1. Remove recovery test 011_crash_recovery.pl

  2. Add a txid_status function.