Re: replay of CREATE TABLESPACE eats data at wal_level=minimal - Mailing list pgsql-hackers

From Noah Misch
Subject Re: replay of CREATE TABLESPACE eats data at wal_level=minimal
Date
Msg-id 20210819053210.GA1636720@rfd.leadboat.com
Whole thread Raw
In response to Re: replay of CREATE TABLESPACE eats data at wal_level=minimal  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: replay of CREATE TABLESPACE eats data at wal_level=minimal
List pgsql-hackers
On Wed, Aug 18, 2021 at 10:47:24AM -0400, Robert Haas wrote:
> On Tue, Aug 10, 2021 at 9:35 AM Robert Haas <robertmhaas@gmail.com> wrote:
> > 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.
> 
> Noah, do you plan to commit this?

Yes.  I feel it needs a test case, which is the main reason I've queued the
task rather than just pushed what I posted last.

On Mon, Aug 09, 2021 at 06:23:07PM -0700, Noah Misch wrote:
> 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.

I wouldn't be surprised if it's possible under some NFS versions, considering
behavior like https://www.spinics.net/lists/linux-nfs/msg59044.html exists.
However, nowhere else do we try to cope with this.  Hence, the fix for
$SUBJECT shouldn't change that pattern.



pgsql-hackers by date:

Previous
From: Greg Nancarrow
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: David Rowley
Date:
Subject: Re: Window Function "Run Conditions"