Re: pg_resetwal --next-transaction-id may cause database failed torestart.
От | Alvaro Herrera |
---|---|
Тема | Re: pg_resetwal --next-transaction-id may cause database failed torestart. |
Дата | |
Msg-id | 20200624150422.GA18409@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: pg_resetwal --next-transaction-id may cause database failed to restart. ("movead.li@highgo.ca" <movead.li@highgo.ca>) |
Ответы |
Re: pg_resetwal --next-transaction-id may cause database failed to restart.
|
Список | pgsql-hackers |
On 2020-Jun-24, movead.li@highgo.ca wrote: > >Maybe a better answer is to have a new switch in postmaster that creates > >any needed files (incl. producing associated WAL etc); so you'd run > >pg_resetwal -x some-value > >postmaster --create-special-stuff > >then start your server and off you go. > > As shown in the document, it looks like to rule a safe input, so I think it's better > to rule it and add an option to focus write an unsafe value if necessary. ISTM that a reasonable compromise is that if you use -x (or -c, -m, -O) and the input value is outside the range supported by existing files, then it's a fatal error; unless you use --force, which turns it into just a warning. > >Now maybe this is too much complication for a mechanism that really > >isn't for general consumption anyway. I mean, if you're using > >pg_resetwal, you're already playing with fire. > Yes, that's true, I always heard the word "You'd better not use pg_walreset". > But the tool appear in PG code, it's better to improve it than do nothing. Sure. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: