From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: replay of CREATE TABLESPACE eats data at wal_level=minimal |
Date: | 2021-08-10 13:35:00 |
Message-ID: | CA+TgmoaNDQWJrVRd9T7+c79db2U7GLZ=paj4xSsRXuauKy8QLw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 9, 2021 at 9:23 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > I don't presently have a specific idea about how to fix this.
>
> Can't recovery just not delete the directory, create it if doesn't exist, and
> be happy if it does exist? Like the attached WIP. If we think it's possible
> for a crash during mkdir to leave a directory having the wrong permissions,
> adding a chmod would be in order.
Oh, yeah, I think that works, actually. I was imagining a few problems
here, but I don't think they really exist. The redo routines for files
within the directory can't possibly care about having the old files
erased for them, since that wouldn't be something that would normally
happen, if there were no recent CREATE TABLESPACE involved. And
there's code further down to remove and recreate the symlink, just in
case. So I think your proposed patch might be all we need.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-08-10 14:10:56 | Re: Postgres perl module namespace |
Previous Message | Nitin Jadhav | 2021-08-10 13:28:38 | Re: when the startup process doesn't (logging startup delays) |