MIME-Version: 1.0
References: 
 <CAAZLFmRK+XFp=mqCeruyNVkqGq5mH45CP+e-8oNttPRtLuB5eQ@mail.gmail.com>
 <ee96443a-72f3-4a12-8ba7-326069fd1c14@eisentraut.org>
 <3793879.1751492926@sss.pgh.pa.us>
 <CAAZLFmTtupwxA33fxVQ69AXG03RjXcoiEmd2soNSAk=Gc4ADkg@mail.gmail.com>
 <10700.1751736853@sss.pgh.pa.us>
 <CAAZLFmSw8wnYo3DYsynEH-Otr0UKQNfeQRoRQzDMmwt0A36kcQ@mail.gmail.com>
In-Reply-To: 
 <CAAZLFmSw8wnYo3DYsynEH-Otr0UKQNfeQRoRQzDMmwt0A36kcQ@mail.gmail.com>
From: Jianghua Yang <yjhjstz@gmail.com>
Date: Fri, 20 Mar 2026 06:32:46 -0700
Message-ID: 
 <CAAZLFmTiZXD3U8Wdu=3WugpoLfgqP1FX=9QinEwiMmvE3GRXPg@mail.gmail.com>
Subject: Re: [PATCH] initdb: Treat empty -U argument as unset username
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
Content-Type: multipart/mixed; boundary="000000000000a69de4064d74ba79"
Archived-At: 
 <https://www.postgresql.org/message-id/CAAZLFmTiZXD3U8Wdu%3D3WugpoLfgqP1FX%3D9QinEwiMmvE3GRXPg%40mail.gmail.com>
Precedence: bulk

--000000000000a69de4064d74ba79
Content-Type: multipart/alternative; boundary="000000000000a69de2064d74ba77"

--000000000000a69de2064d74ba77
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

  The underlying aclitem quoting issue has been fixed in commit 64840e46243
  ("Fix inconsistent quoting of role names in ACLs"), so the concern about
  this patch interfering with that investigation no longer applies.

  Here's a rebased version of the patch. The approach is unchanged from v3:
  reject an empty string passed to -U/--username early with a clear error
  message, rather than letting it fall through to a confusing FATAL during
  bootstrap SQL execution.

  Changes:
  - Add an empty-string check before the existing pg_ prefix check
    in initdb's main(), using pg_fatal().
  - Add a regression test using command_fails_like() to verify the
    error message.

Jianghua Yang <yjhjstz@gmail.com> =E4=BA=8E2025=E5=B9=B47=E6=9C=885=E6=97=
=A5=E5=91=A8=E5=85=AD 10:45=E5=86=99=E9=81=93=EF=BC=9A

> Hi Tom,
>
> Thanks for the clarification.
>
> Just to provide a bit more context =E2=80=94 we encountered this issue in=
 a
> production environment where initdb was being run inside a Docker
> container. In such environments, the $USER environment variable may be
> unset or empty, which causes initdb -U $USER to fail with a confusing
> error.
>
> While it's true that this behavior has existed for a long time, it's
> become more relevant as Docker and containerized deployments have become
> common. This issue can be hard to diagnose for users unfamiliar with the
> internals of initdb, especially since the failure message isn't very
> informative in this case.
>
> I understand your point about not wanting to merge the patch prematurely
> if it could obscure underlying problems. That said, this particular fix
> seems orthogonal to the ACL parsing issue and addresses a real-world
> usability problem with minimal risk.
>
> Would you be open to reconsidering a standalone merge of this patch, or
> perhaps applying a minimal workaround for cases where $USER is unset?
>
> Thanks again for your time and consideration.
>
> Best regards,
> Jianghua Yang
>
> Tom Lane <tgl@sss.pgh.pa.us> =E4=BA=8E2025=E5=B9=B47=E6=9C=885=E6=97=A5=
=E5=91=A8=E5=85=AD 10:34=E5=86=99=E9=81=93=EF=BC=9A
>
>> Jianghua Yang <yjhjstz@gmail.com> writes:
>> > I wanted to ask if this patch can be merged first, as it seems to be a
>> > separate issue different from the aclitem parsing problem Tom discusse=
d
>> in
>> >
>> https://www.postgresql.org/message-id/3792884.1751492172%40sss.pgh.pa.us
>>
>> Merging your patch will make it more difficult to poke at these
>> underlying issues, so I'm not in a hurry to do that.  It's not
>> like this is an urgent issue: initdb has behaved like that for
>> years if not decades, and nobody's complained before.
>>
>>                         regards, tom lane
>>
>

--000000000000a69de2064d74ba77
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>=C2=A0 The underlying aclitem quoting issue has=
 been fixed in commit 64840e46243<br>=C2=A0 (&quot;Fix inconsistent quoting=
 of role names in ACLs&quot;), so the concern about<br>=C2=A0 this patch in=
terfering with that investigation no longer applies.<br><br>=C2=A0 Here&#39=
;s a rebased version of the patch. The approach is unchanged from v3:<br>=
=C2=A0 reject an empty string passed to -U/--username early with a clear er=
ror<br>=C2=A0 message, rather than letting it fall through to a confusing F=
ATAL during<br>=C2=A0 bootstrap SQL execution.<br><br>=C2=A0 Changes:<br>=
=C2=A0 - Add an empty-string check before the existing pg_ prefix check<br>=
=C2=A0 =C2=A0 in initdb&#39;s main(), using pg_fatal().<br>=C2=A0 - Add a r=
egression test using command_fails_like() to verify the<br>=C2=A0 =C2=A0 er=
ror message.</div><br><div class=3D"gmail_quote gmail_quote_container"><div=
 dir=3D"ltr" class=3D"gmail_attr">Jianghua Yang &lt;<a href=3D"mailto:yjhjs=
tz@gmail.com">yjhjstz@gmail.com</a>&gt; =E4=BA=8E2025=E5=B9=B47=E6=9C=885=
=E6=97=A5=E5=91=A8=E5=85=AD 10:45=E5=86=99=E9=81=93=EF=BC=9A<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><p>Hi Tom,</p=
>
<p>Thanks for the clarification.</p>
<p>Just to provide a bit more context =E2=80=94 we encountered this issue i=
n a production environment where <code>initdb</code> was being run inside a=
 Docker container. In such environments, the <code>$USER</code> environment=
 variable may be unset or empty, which causes <code>initdb -U $USER</code> =
to fail with a confusing error.</p>
<p>While it&#39;s true that this behavior has existed for a long time, it&#=
39;s become more relevant as Docker and containerized deployments have beco=
me common. This issue can be hard to diagnose for users unfamiliar with the=
 internals of <code>initdb</code>, especially since the failure message isn=
&#39;t very informative in this case.</p>
<p>I understand your point about not wanting to merge the patch prematurely=
 if it could obscure underlying problems. That said, this particular fix se=
ems orthogonal to the ACL parsing issue and addresses a real-world usabilit=
y problem with minimal risk.</p>
<p>Would you be open to reconsidering a standalone merge of this patch, or =
perhaps applying a minimal workaround for cases where <code>$USER</code> is=
 unset?</p>
<p>Thanks again for your time and consideration.</p>
<p>Best regards,<br>
Jianghua Yang</p></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">Tom Lane &lt;<a href=3D"mailto:tgl@sss.pgh.pa.us" target=
=3D"_blank">tgl@sss.pgh.pa.us</a>&gt; =E4=BA=8E2025=E5=B9=B47=E6=9C=885=E6=
=97=A5=E5=91=A8=E5=85=AD 10:34=E5=86=99=E9=81=93=EF=BC=9A<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">Jianghua Yang &lt;<a href=3D"mail=
to:yjhjstz@gmail.com" target=3D"_blank">yjhjstz@gmail.com</a>&gt; writes:<b=
r>
&gt; I wanted to ask if this patch can be merged first, as it seems to be a=
<br>
&gt; separate issue different from the aclitem parsing problem Tom discusse=
d in<br>
&gt; <a href=3D"https://www.postgresql.org/message-id/3792884.1751492172%40=
sss.pgh.pa.us" rel=3D"noreferrer" target=3D"_blank">https://www.postgresql.=
org/message-id/3792884.1751492172%40sss.pgh.pa.us</a><br>
<br>
Merging your patch will make it more difficult to poke at these<br>
underlying issues, so I&#39;m not in a hurry to do that.=C2=A0 It&#39;s not=
<br>
like this is an urgent issue: initdb has behaved like that for<br>
years if not decades, and nobody&#39;s complained before.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 regards, tom lane<br>
</blockquote></div>
</blockquote></div>

--000000000000a69de2064d74ba77--

--000000000000a69de4064d74ba79
Content-Type: application/octet-stream;
	name="0001-initdb-reject-empty-string-for-U-username-option.patch"
Content-Disposition: attachment;
	filename="0001-initdb-reject-empty-string-for-U-username-option.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mmyxuwfx0>
X-Attachment-Id: f_mmyxuwfx0

RnJvbSBlMDYyZGMxNjRkYTAyNjE5ZjA3MTZmYTc4ZmYwZjllNDIyNDkwYzY1IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBKaWFuZ2h1YSBZYW5nIDx5amhqc3R6QGdtYWlsLmNvbT4KRGF0
ZTogRnJpLCAyMCBNYXIgMjAyNiAwNjozMDowMyAtMDcwMApTdWJqZWN0OiBbUEFUQ0hdIGluaXRk
YjogcmVqZWN0IGVtcHR5IHN0cmluZyBmb3IgLVUvLS11c2VybmFtZSBvcHRpb24KClByZXZpb3Vz
bHksIHBhc3NpbmcgYW4gZW1wdHkgc3RyaW5nIHRvIGluaXRkYidzIC1VIG9wdGlvbiAoZS5nLiwK
aW5pdGRiIC1VICcnKSB3YXMgYWNjZXB0ZWQgd2l0aG91dCBjb21wbGFpbnQsIGJ1dCBsYXRlciBj
YXVzZWQgYQpjb25mdXNpbmcgRkFUQUwgZXJyb3IgZHVyaW5nIGJvb3RzdHJhcCBTUUwgZXhlY3V0
aW9uLgoKQWRkIGFuIGV4cGxpY2l0IGNoZWNrIGZvciBhbiBlbXB0eSBzdXBlcnVzZXIgbmFtZSBi
ZWZvcmUgdGhlIGV4aXN0aW5nCnBnXyBwcmVmaXggdmFsaWRhdGlvbiwgc28gdGhhdCB0aGUgdXNl
ciBnZXRzIGEgY2xlYXIgZXJyb3IgbWVzc2FnZQp1cGZyb250LgoKRGlzY3Vzc2lvbjogaHR0cHM6
Ly9wb3N0Z3IuZXMvbS8xMDcwMC4xNzUxNzM2ODUzQHNzcy5wZ2gucGEudXMKLS0tCiBzcmMvYmlu
L2luaXRkYi9pbml0ZGIuYyAgICAgICAgfCAzICsrKwogc3JjL2Jpbi9pbml0ZGIvdC8wMDFfaW5p
dGRiLnBsIHwgMyArKysKIDIgZmlsZXMgY2hhbmdlZCwgNiBpbnNlcnRpb25zKCspCgpkaWZmIC0t
Z2l0IGEvc3JjL2Jpbi9pbml0ZGIvaW5pdGRiLmMgYi9zcmMvYmluL2luaXRkYi9pbml0ZGIuYwpp
bmRleCA1MDlmMTExNGVmNi4uMjVjZDM5OGNjNmMgMTAwNjQ0Ci0tLSBhL3NyYy9iaW4vaW5pdGRi
L2luaXRkYi5jCisrKyBiL3NyYy9iaW4vaW5pdGRiL2luaXRkYi5jCkBAIC0zNTAwLDYgKzM1MDAs
OSBAQCBtYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pCiAJaWYgKCF1c2VybmFtZSkKIAkJdXNl
cm5hbWUgPSBlZmZlY3RpdmVfdXNlcjsKIAorCWlmICh1c2VybmFtZVswXSA9PSAnXDAnKQorCQlw
Z19mYXRhbCgic3VwZXJ1c2VyIG5hbWUgbXVzdCBub3QgYmUgZW1wdHkiKTsKKwogCWlmIChzdHJu
Y21wKHVzZXJuYW1lLCAicGdfIiwgMykgPT0gMCkKIAkJcGdfZmF0YWwoInN1cGVydXNlciBuYW1l
IFwiJXNcIiBpcyBkaXNhbGxvd2VkOyByb2xlIG5hbWVzIGNhbm5vdCBiZWdpbiB3aXRoIFwicGdf
XCIiLCB1c2VybmFtZSk7CiAKZGlmZiAtLWdpdCBhL3NyYy9iaW4vaW5pdGRiL3QvMDAxX2luaXRk
Yi5wbCBiL3NyYy9iaW4vaW5pdGRiL3QvMDAxX2luaXRkYi5wbAppbmRleCAwODE1MzVhMjJlNC4u
OGM1NDQ2MWZlOTggMTAwNjQ0Ci0tLSBhL3NyYy9iaW4vaW5pdGRiL3QvMDAxX2luaXRkYi5wbAor
KysgYi9zcmMvYmluL2luaXRkYi90LzAwMV9pbml0ZGIucGwKQEAgLTM0LDYgKzM0LDkgQEAgY29t
bWFuZF9mYWlscygKIAlbICdpbml0ZGInLCAnLS13YWxkaXInID0+ICdwZ3hsb2cnLCAkZGF0YWRp
ciBdLAogCSdyZWxhdGl2ZSB4bG9nIGRpcmVjdG9yeSBub3QgYWxsb3dlZCcpOwogCitjb21tYW5k
X2ZhaWxzX2xpa2UoWyAnaW5pdGRiJywgJy0tdXNlcm5hbWUnID0+ICcnLCAkZGF0YWRpciBdLAor
CXFyL3N1cGVydXNlciBuYW1lIG11c3Qgbm90IGJlIGVtcHR5LywKKwknZW1wdHkgdXNlcm5hbWUg
bm90IGFsbG93ZWQnKTsKIGNvbW1hbmRfZmFpbHMoWyAnaW5pdGRiJywgJy0tdXNlcm5hbWUnID0+
ICdwZ190ZXN0JywgJGRhdGFkaXIgXSwKIAkncm9sZSBuYW1lcyBjYW5ub3QgYmVnaW4gd2l0aCAi
cGdfIicpOwogCi0tIAoyLjUwLjEgKEFwcGxlIEdpdC0xNTUpCgo=
--000000000000a69de4064d74ba79--