To: pgsql-general@lists.postgresql.org
From: Timo Schwaak <timo.schwaak@icloud.com>
Subject: =?utf-8?B?SXNzdWUgd2l0aCBQb3N0Z3JlU1FMIEluc3RhbGxlciBvbiBXaW5kb3dzIGFu?=
 =?utf-8?B?ZCBTcGVjaWFsIENoYXJhY3RlcnMgaW4gdGhlIHN1cGVydXNlciBwYXNzd29y?=
 =?utf-8?B?ZA==?=
Date: Fri, 31 May 2024 21:18:17 +0000 (UTC)
Message-id: <35f280da-6547-458c-90ec-1d946c269f9f@me.com>
Content-Type: multipart/alternative; boundary=Apple-Webmail-42--fcd8543f-6129-493f-b3a3-b382ecf6ca5f
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/35f280da-6547-458c-90ec-1d946c269f9f%40me.com>
Precedence: bulk


--Apple-Webmail-42--fcd8543f-6129-493f-b3a3-b382ecf6ca5f
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
    charset=utf-8;
    format=flowed

Dear PostgreSQL community, I hope this is the right place for my concern. =
Today I discovered a strange behaviour of the Windows Installer of Postgre=
SQL. While migrating an application database from MSSQL, the Postgres setu=
p did not seem to complete correctly and had problems starting the Postgre=
s service after installation. I found that the service did not seem to be =
created at all. After some trying around with help I found online, trying =
non-domain users and some other stuff that was proposed for the problem, I=
 found the problem lay in my chosen password. My password was randomly gen=
erated with alphanumeric + special characters. While this did not work, sw=
itching to alphanumeric-only passwords seemed to solve the problem. I susp=
ect that the quotation marks in particular are causing problems in the set=
up, as they seem to terminate some strings prematurely in the scripts used=
 by the installer. My setup was as follows: OS: Windows Server 2019, also =
tested on Windows Server 2022 PSQL version: 16.3 (latest installer from ED=
B) Steps to reproduce: 1. Run the installer 2. Enter any password that con=
tains quotation marks 3. The installer should fail at the end and report s=
ome errors. Could you please help me investigate this, is this a known pro=
blem or is there even a known workaround? If this is not a known issue, ca=
n you help me point this report in the right direction so that it can be a=
ddressed? Best regards, Timo
--Apple-Webmail-42--fcd8543f-6129-493f-b3a3-b382ecf6ca5f
Content-Type: multipart/related;
    type="text/html";
    boundary=Apple-Webmail-86--fcd8543f-6129-493f-b3a3-b382ecf6ca5f


--Apple-Webmail-86--fcd8543f-6129-493f-b3a3-b382ecf6ca5f
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
    charset=utf-8;

<html><body><div>Dear PostgreSQL community, <br></div><div><br></div><div>I hope this =
is the right place for my concern.<br></div><div>Today I discovered a stra=
nge behaviour of the Windows Installer of PostgreSQL.<br></div><div>While =
migrating an application database from MSSQL, the Postgres setup did not s=
eem to complete correctly and had problems starting the Postgres service a=
fter installation. I found that the service did not seem to be created at =
all.<br></div><div>After some trying around with help I found online, tryi=
ng non-domain users and some other stuff that was proposed for the problem=
, I found the problem lay in my chosen password. My password was randomly =
generated with alphanumeric + special characters. While this did not work,=
 switching to alphanumeric-only passwords seemed to solve the problem. I s=
uspect that the quotation marks in particular are causing problems in the =
setup, as they seem to terminate some strings prematurely in the scripts u=
sed by the installer.<br></div><div>My setup was as follows:<br></div><div=
><br></div><div>OS: Windows Server 2019, also tested on Windows Server 202=
2<br></div><div>PSQL version: 16.3 (latest installer from EDB)<br></div><d=
iv>Steps to reproduce:<br></div><div>1. Run the installer<br></div><div>2.=
 Enter any password that contains quotation marks<br></div><div>3. The ins=
taller should fail at the end and report some errors.<br></div><div><br></=
div><div><br></div><div>Could you please help me investigate this, is this=
 a known problem or is there even a known workaround? If this is not a kno=
wn issue, can you help me point this report in the right direction so that=
 it can be addressed?<br></div><div><br></div><div><br></div><div>Best reg=
ards,<br></div><div><br></div><div>Timo<br></div></body></html>
--Apple-Webmail-86--fcd8543f-6129-493f-b3a3-b382ecf6ca5f--

--Apple-Webmail-42--fcd8543f-6129-493f-b3a3-b382ecf6ca5f--