From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de> |
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 06:10:11 |
Message-ID: | 20200918061011.GC2772@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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. If you think about
that, this is rather similar to putting tablespaces in your root data
folder: it may look fancy, but you just make the task of the backend
more complicated. Note that this practice is not wise when Postgres
decides to apply actions that loop across the entire tree, just to
name two of them: the full fsync of PGDATA at the beginning of crash
recovery or just a base backup.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2020-09-18 06:13:52 | Re: logical/relation.c header description |
Previous Message | Michael Paquier | 2020-09-18 05:55:43 | Re: Command statistics system (cmdstats) |