Re: Missing pg_control crashes postmaster
От | David Steele |
---|---|
Тема | Re: Missing pg_control crashes postmaster |
Дата | |
Msg-id | 582c535e-e692-06c3-b821-6f44b0f46e57@pgmasters.net обсуждение исходный текст |
Ответ на | Re: Missing pg_control crashes postmaster (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 7/25/18 11:33 AM, Tom Lane wrote: > David Steele <david@pgmasters.net> writes: >> On 7/25/18 11:09 AM, Andres Freund wrote: >>> The problem is that that'll just hide the issue for a bit longer, while >>> continuing (due to the O_CREAT we'll not PANIC anymore). Which can lead >>> to a lot of followup issues, like checkpoints removing old WAL that'd >>> have been useful for data recovery. > >> So if a panic is the best thing to do, it might still be good to write >> out a copy of pg_control to another file and let the user know that it's >> there. More information seems better than less to me. > > I'm still dubious that this is fixing any real-world problem that is > more pressing than the problems it would create. If you're asked to > resuscitate a dead cluster, do you trust pg_control.bak if you find > it? Maybe it's horribly out of date (consider likelihood that someone > removed pg_control more than once, having got away with that the first > time). If there's both that and pg_control, which do you trust? It would need to be a manual operation. I don't think automating it would be a good idea for the reasons that Andres has enumerated. Perhaps making pg_resetwal a bit smarter in these scenarios would be the way to go. It's already the tool of last resort so this kind of manipulation might be a better fit there. Regards, -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: