From: | Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Alexander Kukushkin <cyberdemn(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Concurrency issue in pg_rewind |
Date: | 2020-09-18 08:50:19 |
Message-ID: | CACACo5SNDz4eSm4MDtZim+XT5nBx34gKB65EocPiWDUNar6-MQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 18, 2020 at 8:10 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Thu, Sep 17, 2020 at 10:20:16AM +0200, Oleksandr Shulgin wrote:
> > Ouch. I think pg_rewind shouldn't try to remove any random files in
> pg_wal
> > that it doesn't know about.
> > What if the administrator made a backup of some WAL segments there?
>
> IMO, this would be a rather bad strategy anyway, so just don't do
> that, because that could also mean that this is on the same partition
> as pg_wal/ which would crash the server if the partition has the idea
> to get full even if max_wal_size is set correctly.
To clarify my point, I don't mean to backup WAL segments in the background
when the server is running, but precisely when the server is down and you
need to intervene, such as running pg_rewind. You might want to "stash"
some of the latest segments in case you need to start over (name it
pg_wal/0000008400000A760000001E.backup, or
pg_wal/backup/0000008400000A760000001E). It is surprising that pg_rewind
might want to decide to remove those.
--
Alex
From | Date | Subject | |
---|---|---|---|
Next Message | Katsuragi Yuta | 2020-09-18 08:53:44 | [PATCH] Add features to pg_stat_statements |
Previous Message | Kyotaro Horiguchi | 2020-09-18 08:28:22 | Re: pgbench calculates summary numbers a wrong way. |