| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_resetwal --next-transaction-id may cause database failed to restart. |
| Date: | 2020-07-08 15:10:03 |
| Message-ID: | CA+TgmobWvNwAod-TBZ-BHRRYXmMGrzHWvmYQNA+o=j72rvbu6g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 24, 2020 at 11:04 AM Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> 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.
One potential problem is that you might be using --force for some
other reason and end up forcing this, too. But maybe that's OK.
Perhaps we should consider the idea of having pg_resetwal create the
relevant clog file and zero-fill it, if it doesn't exist already,
rather than leaving that to to the DBA or the postmaster binary to do
it. It seems like that is what people would want to happen in this
situation.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2020-07-08 15:37:57 | Re: max_slot_wal_keep_size and wal_keep_segments |
| Previous Message | Juan José Santamaría Flecha | 2020-07-08 15:07:08 | Re: TAP tests and symlinks on Windows |