From: | "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca> |
---|---|
To: | "Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_resetwal --next-transaction-id may cause database failed to restart. |
Date: | 2020-06-24 08:49:31 |
Message-ID: | 2020062416492731374415@highgo.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>Yeah, the normal workaround is to create the necessary file manually in
>order to let the system start after such an operation; they are
>sometimes necessary to enable testing weird cases with wraparound and
>such. So a total rejection to work for these cases would be unhelpful
>precisely for the scenario that those switches were intended to serve.
I think these words should appear in pg_resetwal document if we decide
to do nothing for this issue.
>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.
>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.
Regards,
Highgo Software (Canada/China/Pakistan)
URL : www.highgo.ca
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-06-24 09:00:23 | Re: Removal of currtid()/currtid2() and some table AM cleanup |
Previous Message | Bharath Rupireddy | 2020-06-24 08:46:23 | Re: Parallel copy |