Re: Concurrency issue in pg_rewind

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

In response to

Browse pgsql-hackers by date

  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.