Date: Tue, 29 Mar 2022 13:37:34 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: robertmhaas@gmail.com, michael@paquier.xyz, rjuju123@gmail.com,
	pgsql-hackers@postgresql.org
Subject: Re: standby recovery fails (tablespace related) (tentative patch and
 discussion)
Message-ID: <202203291137.ys7fq7g4ehte@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20220329.135535.310000883119475499.horikyota.ntt@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202203291137.ys7fq7g4ehte%40alvherre.pgsql>
Precedence: bulk

On 2022-Mar-29, Kyotaro Horiguchi wrote:

> > That's going to result in a call to
> > XLogReadBufferForRedoExtended() which will call
> > XLogReadBufferExtended() which will do smgrcreate(smgr, forknum, true)
> > which will in turn call TablespaceCreateDbspace() to fill in all the
> > missing directories.
> 
> Right. I thought that recovery avoids that but that's wrong.  This
> behavior creates a bare (non-linked) directly within pg_tblspc.  The
> directory would dissapear soon if recovery proceeds to the consistency
> point, though.

Hmm, this is not good.

> No. I agree that mixing them is not good.  On the other hand we
> already doing that by heapam.  AFAICS sometimes it avoid creating a
> new page but sometimes creates it.  But I don't mean to use the fact
> for justifying this patch to do that, or denying to do that.

I think we should revert this patch and do it again using the other
approach: create a stub directory during recovery that can be deleted
later.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Porque francamente, si para saber manejarse a uno mismo hubiera que
rendir examen... ¿Quién es el machito que tendría carnet?"  (Mafalda)