Re: replay of CREATE TABLESPACE eats data at wal_level=minimal

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

In response to

Responses

Browse pgsql-hackers by date

  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)