| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Jeremy Schneider <schneider(at)ardentperf(dot)com> |
| Subject: | Re: [HACKERS] pg_upgrade to clusters with a different WAL segment size |
| Date: | 2017-11-14 00:23:00 |
| Message-ID: | CAB7nPqRkgnC4mZ1Gb+tfqNSx_h6OE-VjuS3jK1h7sQBRz2xK3w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 14, 2017 at 8:38 AM, Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
> Fair points. If we added an option to pg_resetwal, should we bother
> trying to handle the WAL filename overlap that Jeremy mentioned? The
> -l option gives us the ability to set the WAL starting address
> manually, but it might not be terribly clear to end users that this is
> something to watch out for.
After running an upgrade the previous WAL segments become useless, and
that's the same when changing a segment size. Even if you take care of
having the pg_resetwal-ed cluster using a segment name ahead of what
the previous cluster is using, you still run after the risk of having
other nodes with the previous segment size overwrite the WAL segments
of the new size. In short, that's only a matter of being careful with
your archive locations.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2017-11-14 00:32:51 | Re: [COMMITTERS] pgsql: Add hash partitioning. |
| Previous Message | Kohei KaiGai | 2017-11-14 00:11:20 | FP16 Support? |