DKIM2-Signature: i=1; m=1; t=1790912971; d=paquier.xyz;
	mf=PG1pY2hhZWxAcGFxdWllci54eXo+;
	rt=PHBnc3FsLWJ1Z3NAbGlzdHMucG9zdGdyZXNxbC5vcmc+;
	s=fm1:rsa-sha256:bYNelwsZtWY/0DScf5l0bIsaP9iFT6Y1ftllenz4XOou0WE
	Yu3XK2W6R6WGGngv1zJHhC12+zy+a2kyGwBKgKLlzC/JWioXQsdWkA1QJCoesuUI
	4snwsaH4/2xGG7yBTn4rdIjGthHzZS5D/b9lAJIY2WmCCIb4DEyIth3orTBlzlRH
	/WHNzHj27GukAnG4lK9RvrHB5PMQxnb6gAS77ewWzAOxAxKAcYfFQiruW5K3NqEn
	U03D0AaHJfcd9PFHzGOPcT6qXv6abzvNmyEvwgjjCV1f3ADUcyt5+hQP1CFXK1c6
	NcFQrLpqK733qu/0mV4zAUHCdCKRb3gvxXmjjWA==;
Message-Instance: m=1;
 h=sha256:Fotc/kp7/lrmQ0CdTpRzAfAc/4RGz6lGJLLKCxie4Zs=:7rWkg/lEZtXXwTxRqtjB1zckbYkrQQD9BfUdqbAWIp0=;
Feedback-ID: i0fe9450f:Fastmail
Date: Fri, 2 Oct 2026 12:49:27 +0900
From: Michael Paquier <michael@paquier.xyz>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: shihao zhong <zhong950419@gmail.com>,
	"theshallow27@gmail.com" <theshallow27@gmail.com>,
	"pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #19730: PostgreSQL `pg_backup_start` accepts newlines in the
 backup label, producing an unrestorable `backup
Message-ID: <ar8px1yG51ESobdm@paquier.xyz>
References: <19730-85a6044c9e72774a@postgresql.org>
 <CAGRkXqTGP7BRT5Xv+xJoSc3egpPtC0h-LH-w4GxzQSt5qg7iLg@mail.gmail.com>
 <CAKFQuwbjp=jg5_K3W3pP8cuO68B5R=NOuRRo6ZCvTMyZMyW8rQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="FzHWxuxcDz6qiRko"
Content-Disposition: inline
In-Reply-To: 
 <CAKFQuwbjp=jg5_K3W3pP8cuO68B5R=NOuRRo6ZCvTMyZMyW8rQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ar8px1yG51ESobdm%40paquier.xyz>
Precedence: bulk

--FzHWxuxcDz6qiRko
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 01, 2026 at 08:25:05PM -0700, David G. Johnston wrote:
> The fix request seems like something we should just do barring foreseen
> issues doing so.  The system should not accept inputs it knows are
> incompatible with the output it needs to produce.  I agree there isn=E2=
=80=99t a
> reason to try and make this usage actually work.

I tend to agree with you here.  There is no real use case in allowing
CR and LF characters in backup label names.  If somebody has the idea
to abuse of that to introduce custom data into a label file, that's
probably a very bad idea anyway because it would overwrite the fields
a backend things are the good ones when producing the backup_label
file, leading to a most-probably broken instance.

In short, I'm on board with the addition of an extra check that
enforces this policy in do_pg_backup_start(), marking label files
coming from the SQL functions as much as the replication command
BASE_BACKUP.

Side note: v19 now disallows CRLFs in role, database and tablespace
names, see b380a56a3f95 and the reasons why.  The same reasons do not
apply here, and are much lighter as a CRLF would only manipulate a
server to do an incorrect recovery.  Like the other one, that's just
wrong.

Perhaps we should add one test query somewhere in a TAP script of
src/test/recovery/, while on it.
--
Michael

--FzHWxuxcDz6qiRko
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmq/KccACgkQnvQgOdby
QH0dAw//a1sdZY96fJUh1TroEqqQmCf6w4o2um6gxChwO+a+ybWdbevfW1VbCP+m
4/o0S2IoQr7Fd0fXHxI6EwOixoUC+dZpB4XoD0q06+3xSyGWtC5Ka3htd8QELlXl
hSsS9O6+u7RS83jt4AicztDpt5IxqSZaVViwkv1yfRa4N1AvEnIyZ9cDj4Crr/50
F1XBs8AnAhur1yDoppRYgkHq6x/oIUCVYLOvf6s3tObbvOR8LSDH3KBcfdWy1SJP
2QC2GIzjyez7GBLGJbe4Jkwrlfmlr4jUe1t5isG7gV5KWgFTzZzETRMs6PezYTfa
iw9p1z0LY0RAlN4VMrwKznC3wum7sduOJ+QdMT1jWr5xMyijIW55KtNIbnBOEISx
d1gIEd3MSwEnht0Uch8Fkar/XYVQ67nvTMvrxJw8lBwxVjxXrg1x6J+5K3w6SfNN
7g5jovx9L2sufBNNP+m3f3zWyaZt82cPFsOJ157f7BnF0eEVANlZr+57gwAcAz9K
DQ6PApXDqt8t+S7TBcZb953pNCdopFxpsZGMdd704xT1krz2RuIHFHuaBTtZZPA8
xqzi7ECACJKHWII69MN39heBwB9P29VUXPiKDgfV1ZHx+WtygAegt8OBiMGLljKH
T4PDHk+jW/HhfXjpsTZag1TmeZSh2mm8kfIq3Vht4wl6BAYDgaI=
=2hz8
-----END PGP SIGNATURE-----

--FzHWxuxcDz6qiRko--