Feedback-ID: ia2694551:Fastmail
Date: Wed, 13 Jul 2022 18:43:45 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: dilipbalaut@gmail.com, 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: <20220713164345.j3n67rc45rpa4vop@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="fjxxjvhdbrq5f7rb"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20220405.171857.1673205520427411283.horikyota.ntt@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20220713164345.j3n67rc45rpa4vop%40alvherre.pgsql>
Precedence: bulk


--fjxxjvhdbrq5f7rb
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Not a review, just a preparatory rebase across some trivially
conflicting changes.  I also noticed that
src/test/recovery/t/031_recovery_conflict.pl, which was added two days
after v23 was sent, and which uses allow_in_place_tablespaces, bails out
because of the checks introduced by this patch, so I made the check
routine do nothing in that case.

Anyway, here's v24.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"La conclusión que podemos sacar de esos estudios es que
no podemos sacar ninguna conclusión de ellos" (Tanenbaum)

--fjxxjvhdbrq5f7rb
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
	filename="v24-0001-Fix-replay-of-create-database-records-on-standby.patch"