Hi Michael Paquier
Thank you for the information you provided，
Thanks
On Tue, 24 Dec 2024 at 13:13, Michael Paquier <mich...@paquier.xyz> wrote:
> 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
>
