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
