Re: transaction lost when delete clog file after normal shutdown

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: wenhui qiu <qiuwenhuifx(at)gmail(dot)com>
Cc: Jan Wieck <jan(at)wi3ck(dot)info>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: transaction lost when delete clog file after normal shutdown
Date: 2024-12-24 05:13:28
Message-ID: Z2pC-L7b1l8l47OI@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 24, 2024 at 09:55:09AM +0800, wenhui qiu wrote:
> However, on the other hand, oracle has many solutions to open the database
> after the data files are damaged, and his intention should be to start the
> database even if some critical files are damaged to salvage the data
> inside.Because there's a lot of that going on in the real world, and you
> can't change that by firing the dba.

So does Postgres, at least partially depending on the state of the
cluster (for example, see ways to bypass catalog indexes to be able to
log in). FWIW, I can be easily convinced that more tooling in this
area to help folks do low-level chirurgy on the on-disk files of a
data folder while a server is running is cool to have, like
pg_surgery:
https://www.postgresql.org/docs/devel/pgsurgery.html

If you have suggestions about ways that would help, feel free to
propose them.

Anyway, if it comes to corruption, these tools should only be used if
you don't have a backup, and only to retrieve data from a data folder
to then do a logical copy of it to a freshly initialized data folder,
most likely on a different host or partition, if you suspect that your
disk is at fault for example.

If you see an issue in the backend code, even a tiny window where we
could lose data because we are missing a flush or manipulate files so
as consistency is not guaranteed post-crash, that would be worth
discussing on the ground of being a legit bug. Manual removal of
on-disk files is not that.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-12-24 05:35:16 Re: per backend I/O statistics
Previous Message Michael Paquier 2024-12-24 05:01:15 Re: stored procedures vs pg_stat_statements