| From: | Andrey Borodin <amborodin86(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz> |
| Subject: | Re: Something is wrong with wal_compression |
| Date: | 2023-01-26 21:28:50 |
| Message-ID: | CAAhFRxjQT0_Yc3P1Aph1mB6JUEyh5Ly92SHDQFSa5Qi2bBx9ng@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 26, 2023 at 12:12 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
It was discussed long before WAL compression here [0]. The thing is it
is easier to reproduce with compression, but compression has nothing
to do with it, as far as I understand.
Proposed fix is here[1], but I think it's better to fix the test. It
should not veryfi Xid, but rather side effects of "CREATE TABLE mine(x
integer);".
Best regards, Andrey Borodin.
[0] https://www.postgresql.org/message-id/flat/565FB155-C6B0-41E2-8C44-7B514DC25132%2540yandex-team.ru
[1] https://www.postgresql.org/message-id/flat/20210313012820.GJ29463%40telsasoft.com#0f18d3a4d593ea656fdc761e026fee81
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2023-01-26 21:39:30 | Re: GUCs to control abbreviated sort keys |
| Previous Message | Nathan Bossart | 2023-01-26 21:22:55 | Re: suppressing useless wakeups in logical/worker.c |