agora inbox for [email protected]
help / color / mirror / Atom feedBUG #18379: LDAP bind password exposed
12+ messages / 8 participants
[nested] [flat]
* BUG #18379: LDAP bind password exposed
@ 2024-03-06 13:51 PG Bug reporting form <[email protected]>
2024-03-06 15:40 ` Re: BUG #18379: LDAP bind password exposed Tom Lane <[email protected]>
2024-03-06 15:46 ` Re: BUG #18379: LDAP bind password exposed Laurenz Albe <[email protected]>
0 siblings, 2 replies; 12+ messages in thread
From: PG Bug reporting form @ 2024-03-06 13:51 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
The following bug has been logged on the website:
Bug reference: 18379
Logged by: Vinícius Coelho
Email address: [email protected]
PostgreSQL version: 15.3
Operating system: Ubuntu 22.04
Description:
Dear PostgreSQL Support Team,
I am writing to seek your assistance regarding a security concern we have
encountered with our PostgreSQL database setup. We are currently utilizing
LDAP authentication as specified in our pg_hba.conf file. However, upon
reviewing the PostgreSQL logs, we have observed an issue that is causing us
significant concern.
Whenever a login attempt is made using LDAP authentication, the entire
configuration line from the pg_hba.conf file is being logged in the
PostgreSQL log files. This includes the LDAP bind password (ldapbindpasswd),
which is being recorded in plaintext. This practice poses a serious security
risk, as it exposes sensitive credentials in log files that might be
accessed by unauthorized individuals.
We are seeking guidance on how to address this issue. Specifically, we would
like to know:
If there is a configuration option available that prevents the logging of
sensitive information, particularly the LDAP bind password, in the
PostgreSQL logs.
Any recommended best practices for securing our LDAP authentication setup
with PostgreSQL, to avoid similar issues in the future.
If this behavior is known and if there are any patches or updates available
that we should apply to our PostgreSQL installation to resolve this
concern.
We prioritize the security of our database and the protection of sensitive
information. Therefore, we are eager to resolve this issue as promptly as
possible. Any assistance or insights you could provide on this matter would
be greatly appreciated.
Thank you in advance for your time and support. We look forward to your
prompt response and any recommendations you may have.
Best regards,
Vinícius Coelho
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18379: LDAP bind password exposed
2024-03-06 13:51 BUG #18379: LDAP bind password exposed PG Bug reporting form <[email protected]>
@ 2024-03-06 15:40 ` Tom Lane <[email protected]>
2024-03-06 18:40 ` Re: BUG #18379: LDAP bind password exposed Stephen Frost <[email protected]>
1 sibling, 1 reply; 12+ messages in thread
From: Tom Lane @ 2024-03-06 15:40 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
PG Bug reporting form <[email protected]> writes:
> Whenever a login attempt is made using LDAP authentication, the entire
> configuration line from the pg_hba.conf file is being logged in the
> PostgreSQL log files. This includes the LDAP bind password (ldapbindpasswd),
> which is being recorded in plaintext. This practice poses a serious security
> risk, as it exposes sensitive credentials in log files that might be
> accessed by unauthorized individuals.
We do not consider this a bug. There are very many ways that
sensitive information could appear in the postmaster log file.
There's no way to block them all, not least because some items
are ones that the server could not know are sensitive (consider
for instance credit card details, or medical information in a
database under HIPAA rules). You *must* make arrangements to
secure the postmaster log equally carefully as the database itself.
Having said that, you might consider moving away from LDAP
authentication. It's not considered best practice anymore,
notably because it requires the server to see the user's
unencrypted password, and then turn around and pass that on
to the LDAP server. GSSAPI/SSPI (a/k/a Kerberos, or Active
Directory in the Microsoft universe) provide substantially
better centralized authentication technology that's more
secure in quite a few ways.
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18379: LDAP bind password exposed
2024-03-06 13:51 BUG #18379: LDAP bind password exposed PG Bug reporting form <[email protected]>
2024-03-06 15:40 ` Re: BUG #18379: LDAP bind password exposed Tom Lane <[email protected]>
@ 2024-03-06 18:40 ` Stephen Frost <[email protected]>
2024-03-06 19:52 ` Re: BUG #18379: LDAP bind password exposed Tom Lane <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Stephen Frost @ 2024-03-06 18:40 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: [email protected]; [email protected]
Greetings,
* Tom Lane ([email protected]) wrote:
> PG Bug reporting form <[email protected]> writes:
> > Whenever a login attempt is made using LDAP authentication, the entire
> > configuration line from the pg_hba.conf file is being logged in the
> > PostgreSQL log files. This includes the LDAP bind password (ldapbindpasswd),
> > which is being recorded in plaintext. This practice poses a serious security
> > risk, as it exposes sensitive credentials in log files that might be
> > accessed by unauthorized individuals.
>
> We do not consider this a bug. There are very many ways that
> sensitive information could appear in the postmaster log file.
> There's no way to block them all, not least because some items
> are ones that the server could not know are sensitive (consider
> for instance credit card details, or medical information in a
> database under HIPAA rules). You *must* make arrangements to
> secure the postmaster log equally carefully as the database itself.
While I agree that users should take steps to secure their log files,
I'd argue that it's best practice to avoid dumping sensitive data into
log files, which it seems like it would be in this case. I'm not
suggesting that this is bug-worthy or that we should go to excessive
lengths to try and prevent every such case, but if someone showed up
with a reasonable patch to replace the sensitive information in a pg_hba
line with ****, I would be on the side of supporting that.
> Having said that, you might consider moving away from LDAP
> authentication. It's not considered best practice anymore,
> notably because it requires the server to see the user's
> unencrypted password, and then turn around and pass that on
> to the LDAP server. GSSAPI/SSPI (a/k/a Kerberos, or Active
> Directory in the Microsoft universe) provide substantially
> better centralized authentication technology that's more
> secure in quite a few ways.
Fully agree with this. The best approach to dealing with this is to
move away from PG's 'ldap' auth type.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18379: LDAP bind password exposed
2024-03-06 13:51 BUG #18379: LDAP bind password exposed PG Bug reporting form <[email protected]>
2024-03-06 15:40 ` Re: BUG #18379: LDAP bind password exposed Tom Lane <[email protected]>
2024-03-06 18:40 ` Re: BUG #18379: LDAP bind password exposed Stephen Frost <[email protected]>
@ 2024-03-06 19:52 ` Tom Lane <[email protected]>
2024-03-07 06:34 ` Re: BUG #18379: LDAP bind password exposed Stephen Frost <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Tom Lane @ 2024-03-06 19:52 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: [email protected]; [email protected]
Stephen Frost <[email protected]> writes:
> While I agree that users should take steps to secure their log files,
> I'd argue that it's best practice to avoid dumping sensitive data into
> log files, which it seems like it would be in this case. I'm not
> suggesting that this is bug-worthy or that we should go to excessive
> lengths to try and prevent every such case, but if someone showed up
> with a reasonable patch to replace the sensitive information in a pg_hba
> line with ****, I would be on the side of supporting that.
I dunno, I think it would mostly serve to set false expectations.
We've repeatedly rejected requests to scrub the log of passwords
found in CREATE/ALTER USER commands, for example. I think some
of the same issues that led to that conclusion would apply here,
notably that a syntax error could lead to failing to recognize
at all that some substring is a password. (A visibly erroneous
pg_hba line would not get quoted in the specific context the OP
complains of, but I'm pretty sure we'd print it while logging
the configuration reload failure.)
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18379: LDAP bind password exposed
2024-03-06 13:51 BUG #18379: LDAP bind password exposed PG Bug reporting form <[email protected]>
2024-03-06 15:40 ` Re: BUG #18379: LDAP bind password exposed Tom Lane <[email protected]>
2024-03-06 18:40 ` Re: BUG #18379: LDAP bind password exposed Stephen Frost <[email protected]>
2024-03-06 19:52 ` Re: BUG #18379: LDAP bind password exposed Tom Lane <[email protected]>
@ 2024-03-07 06:34 ` Stephen Frost <[email protected]>
2024-03-27 07:42 ` Re: BUG #18379: LDAP bind password exposed Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Stephen Frost @ 2024-03-07 06:34 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: [email protected]; [email protected]
Greetings,
* Tom Lane ([email protected]) wrote:
> Stephen Frost <[email protected]> writes:
> > While I agree that users should take steps to secure their log files,
> > I'd argue that it's best practice to avoid dumping sensitive data into
> > log files, which it seems like it would be in this case. I'm not
> > suggesting that this is bug-worthy or that we should go to excessive
> > lengths to try and prevent every such case, but if someone showed up
> > with a reasonable patch to replace the sensitive information in a pg_hba
> > line with ****, I would be on the side of supporting that.
>
> I dunno, I think it would mostly serve to set false expectations.
I appreciate that concern. I don't think it will though.
> We've repeatedly rejected requests to scrub the log of passwords
> found in CREATE/ALTER USER commands, for example. I think some
> of the same issues that led to that conclusion would apply here,
> notably that a syntax error could lead to failing to recognize
> at all that some substring is a password. (A visibly erroneous
> pg_hba line would not get quoted in the specific context the OP
> complains of, but I'm pretty sure we'd print it while logging
> the configuration reload failure.)
While this may not be popular, I'd be in support of doing away with
support for cleartext passwords being accepted through CREATE/ALTER USER
commands, therefore eliminating this issue entirely. As discussed on
this very thread, passing passwords in the clear from the client to the
server, in any context, goes against best practices, which is why PG's
ldap auth method is discouraged as it does exactly that.
Doing this would, ideally at least, result in a lot more use of libpq's
PQchangePassword() and \password in psql, which would further reduce the
chances of a syntax error ending up dumping sensitive data into the log
(the server's SCRAM password authenticator would still be considered
sensitive and worthy of hiding, imv, but I wouldn't push as hard on that
as it's clearly less of a risk than the user's cleartext password).
Sure, mistakes could still happen and we couldn't do anything about it
(a user might *try* to pass in a cleartext password via ALTER USER *and*
have a syntax mistake), but now we're really looking at low probability
issues.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (833B, ../../Zelf%[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18379: LDAP bind password exposed
2024-03-06 13:51 BUG #18379: LDAP bind password exposed PG Bug reporting form <[email protected]>
2024-03-06 15:40 ` Re: BUG #18379: LDAP bind password exposed Tom Lane <[email protected]>
2024-03-06 18:40 ` Re: BUG #18379: LDAP bind password exposed Stephen Frost <[email protected]>
2024-03-06 19:52 ` Re: BUG #18379: LDAP bind password exposed Tom Lane <[email protected]>
2024-03-07 06:34 ` Re: BUG #18379: LDAP bind password exposed Stephen Frost <[email protected]>
@ 2024-03-27 07:42 ` Andrew Dunstan <[email protected]>
0 siblings, 0 replies; 12+ messages in thread
From: Andrew Dunstan @ 2024-03-27 07:42 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]; [email protected]
On Thu, Mar 7, 2024 at 1:34 AM Stephen Frost <[email protected]> wrote:
> Greetings,
>
> * Tom Lane ([email protected]) wrote:
> > Stephen Frost <[email protected]> writes:
> > > While I agree that users should take steps to secure their log files,
> > > I'd argue that it's best practice to avoid dumping sensitive data into
> > > log files, which it seems like it would be in this case. I'm not
> > > suggesting that this is bug-worthy or that we should go to excessive
> > > lengths to try and prevent every such case, but if someone showed up
> > > with a reasonable patch to replace the sensitive information in a
> pg_hba
> > > line with ****, I would be on the side of supporting that.
> >
> > I dunno, I think it would mostly serve to set false expectations.
>
> I appreciate that concern. I don't think it will though.
>
> > We've repeatedly rejected requests to scrub the log of passwords
> > found in CREATE/ALTER USER commands, for example. I think some
> > of the same issues that led to that conclusion would apply here,
> > notably that a syntax error could lead to failing to recognize
> > at all that some substring is a password. (A visibly erroneous
> > pg_hba line would not get quoted in the specific context the OP
> > complains of, but I'm pretty sure we'd print it while logging
> > the configuration reload failure.)
>
> While this may not be popular, I'd be in support of doing away with
> support for cleartext passwords being accepted through CREATE/ALTER USER
> commands, therefore eliminating this issue entirely. As discussed on
> this very thread, passing passwords in the clear from the client to the
> server, in any context, goes against best practices, which is why PG's
> ldap auth method is discouraged as it does exactly that.
>
> Doing this would, ideally at least, result in a lot more use of libpq's
> PQchangePassword() and \password in psql, which would further reduce the
> chances of a syntax error ending up dumping sensitive data into the log
> (the server's SCRAM password authenticator would still be considered
> sensitive and worthy of hiding, imv, but I wouldn't push as hard on that
> as it's clearly less of a risk than the user's cleartext password).
>
> Sure, mistakes could still happen and we couldn't do anything about it
> (a user might *try* to pass in a cleartext password via ALTER USER *and*
> have a syntax mistake), but now we're really looking at low probability
> issues.
>
>
All the philosophical stuff aside, I think this could be avoided by the
deployment of an ldap_password_hook, which is designed to allow mangling of
the bindpasswd before it's passed to the ldap server. There's a trivial
example in src/test/modules/ldap_password_func
It's available in release 16, so the OP would need to upgrade.
cheers
andrew
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #18379: LDAP bind password exposed
2024-03-06 13:51 BUG #18379: LDAP bind password exposed PG Bug reporting form <[email protected]>
@ 2024-03-06 15:46 ` Laurenz Albe <[email protected]>
1 sibling, 0 replies; 12+ messages in thread
From: Laurenz Albe @ 2024-03-06 15:46 UTC (permalink / raw)
To: [email protected]; [email protected]
On Wed, 2024-03-06 at 13:51 +0000, PG Bug reporting form wrote:
> PostgreSQL version: 15.3
>
> I am writing to seek your assistance regarding a security concern we have
> encountered with our PostgreSQL database setup. We are currently utilizing
> LDAP authentication as specified in our pg_hba.conf file. However, upon
> reviewing the PostgreSQL logs, we have observed an issue that is causing us
> significant concern.
>
> Whenever a login attempt is made using LDAP authentication, the entire
> configuration line from the pg_hba.conf file is being logged in the
> PostgreSQL log files. This includes the LDAP bind password (ldapbindpasswd),
> which is being recorded in plaintext. This practice poses a serious security
> risk, as it exposes sensitive credentials in log files that might be
> accessed by unauthorized individuals.
There is no way to prevent that short of stopping to log errors.
But I am afraid that that won't be your only problem if you let unauthorized
individuals read your log files. Any statement that causes an error and
contains sensitive information will become a problem, and if you set
"log_statement = 'ddl'", anybody who changes their password without
encrypting it on the client side will find the password in the log.
Log files should be treated as sensitive data.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 12+ messages in thread
* BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows
@ 2026-06-30 07:37 PG Bug reporting form <[email protected]>
2026-07-01 08:40 ` Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: PG Bug reporting form @ 2026-06-30 07:37 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
The following bug has been logged on the website:
Bug reference: 19541
Logged by: Karen Huang
Email address: [email protected]
PostgreSQL version: 19beta1
Operating system: Windows 11
Description:
The MSVC team regularly builds popular open-source projects, including
yours, with development versions of the build tools in order to find and fix
regressions in the compiler and libraries before they can ship and cause
trouble for the world. This also allows us to provide advance notice of
breaking changes, which is the case here.
We build Postgresql with VS 2026 on Windows. It failed to run 150+ tests on
both debug and release configurations. Could you please help to take a look?
Thanks in advance!
Repro steps:
1. git clone https://git.postgresql.org/git/postgresql.git
C:\gitP\postgres\postgres
2. C:\tools\msys64\usr\bin\pacman --noconfirm -S flex bison diffutils
3. Open VS 2026 x64 CMD.
4. cd /d C:\gitP\postgres\postgres
5. mkdir build_amd64 && cd build_amd64
6. set PATH=%PATH%;C:\tools\msys64\usr\bin
7. pip3 install meson
8. meson setup --buildtype release
9. ninja -v
10. meson test --no-suite libpq_pipeline
Test result:
The error log is quite large, so it's not practical to paste it into the
email. It also appears that we can't attach log files to this thread. Could
you please advise on the preferred way to share the complete log? We can
upload it to a file-sharing service or use any other method you recommend.
=================================== 7/383
====================================
test: recovery - postgresql:recovery/001_stream_rep
start time: 02:28:46
duration: 84.25s
result: exit status 9
command: top_builddir=C:\gitP\postgres\postgres\build_amd64
enable_injection_points=no
MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
MALLOC_PERTURB_=88
share_contrib_dir=C:/gitP/postgres/postgres/build_amd64/tmp_install//usr/local/pgsql/share/contrib
PG_REGRESS=C:\gitP\postgres\postgres\build_amd64\src/test\regress\pg_regress.exe
INITDB_TEMPLATE=C:/gitP/postgres/postgres/build_amd64/tmp_install/initdb-template
REGRESS_SHLIB=C:\gitP\postgres\postgres\build_amd64\src/test\regress\regress.dll
MESON_TEST_ITERATION=1
ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1
C:\Python312\python.EXE
C:\gitP\postgres\postgres\build_amd64\..\src/tools/testwrap --basedir
C:\gitP\postgres\postgres\build_amd64 --srcdir
C:\gitP\postgres\postgres\src/test\recovery --pg-test-extra --testgroup
recovery --testname 001_stream_rep -- C:\Strawberry\perl\bin\perl.EXE -I
C:/gitP/postgres/postgres/src/test/perl -I
C:\gitP\postgres\postgres\src/test\recovery
C:/gitP/postgres/postgres/src/test/recovery/t/001_stream_rep.pl
----------------------------------- stdout
-----------------------------------
# executing test in
C:\gitP\postgres\postgres\build_amd64/testrun/recovery/001_stream_rep group
recovery test 001_stream_rep
# initializing database system by copying initdb template
1..0
# test failed
----------------------------------- stderr
-----------------------------------
# die: WAIT FOR LSN failed: error running SQL: 'psql:<stdin>:1: ERROR:
invalid input syntax for type pg_lsn: "0/03045AA0
"
'
# while running 'psql --no-psqlrc --no-align --tuples-only --quiet --dbname
port=30741 host=127.0.0.1 dbname='postgres' --file - --variable
ON_ERROR_STOP=1' with sql 'WAIT FOR LSN '0/03045AA0
' WITH (MODE 'standby_replay', timeout '180s', no_throw);' at
C:/gitP/postgres/postgres/src/test/recovery/t/001_stream_rep.pl line 72.
# at C:/gitP/postgres/postgres/src/test/recovery/t/001_stream_rep.pl line
72.
(test program exited with status code 9)
==============================================================================
....
Ok: 174
Fail: 154
Skipped: 46
Timeout: 8
Thanks,
Karen
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows
2026-06-30 07:37 BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows PG Bug reporting form <[email protected]>
@ 2026-07-01 08:40 ` Kyotaro Horiguchi <[email protected]>
2026-07-13 06:09 ` Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows Karen Huang <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Kyotaro Horiguchi @ 2026-07-01 08:40 UTC (permalink / raw)
To: [email protected]; [email protected]
At Tue, 30 Jun 2026 07:37:00 +0000, PG Bug reporting form <[email protected]> wrote in
> # die: WAIT FOR LSN failed: error running SQL: 'psql:<stdin>:1: ERROR:
> invalid input syntax for type pg_lsn: "0/03045AA0
> "
> '
> # while running 'psql --no-psqlrc --no-align --tuples-only --quiet --dbname
> port=30741 host=127.0.0.1 dbname='postgres' --file - --variable
> ON_ERROR_STOP=1' with sql 'WAIT FOR LSN '0/03045AA0
> ' WITH (MODE 'standby_replay', timeout '180s', no_throw);' at
> C:/gitP/postgres/postgres/src/test/recovery/t/001_stream_rep.pl line 72.
chomp doesn't seem to be working as expected. Are you using Strawberry
Perl? The documentation states that Strawberry Perl is required for
Windows builds. Are you using the correct Perl?
https://www.postgresql.org/docs/devel/installation-platform-notes.html#WINDOWS-REQUIREMENTS
> Strawberry Perl is required to run the build generation
> scripts. MinGW or Cygwin Perl will not work. It must also be present
> in the PATH. Binaries can be downloaded from
> https://strawberryperl.com.
Regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows
2026-06-30 07:37 BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows PG Bug reporting form <[email protected]>
2026-07-01 08:40 ` Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows Kyotaro Horiguchi <[email protected]>
@ 2026-07-13 06:09 ` Karen Huang <[email protected]>
2026-07-13 07:21 ` Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows Karen Huang <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Karen Huang @ 2026-07-13 06:09 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]
Yes, we are using the Strawberry Perl. It can be found in CMD like below:
>where perl
C:\Strawberry\perl\bin\perl.exe
On Wed, Jul 1, 2026 at 4:40 PM Kyotaro Horiguchi <[email protected]>
wrote:
> At Tue, 30 Jun 2026 07:37:00 +0000, PG Bug reporting form <
> [email protected]> wrote in
> > # die: WAIT FOR LSN failed: error running SQL: 'psql:<stdin>:1: ERROR:
> > invalid input syntax for type pg_lsn: "0/03045AA0
> > "
> > '
> > # while running 'psql --no-psqlrc --no-align --tuples-only --quiet
> --dbname
> > port=30741 host=127.0.0.1 dbname='postgres' --file - --variable
> > ON_ERROR_STOP=1' with sql 'WAIT FOR LSN '0/03045AA0
> > ' WITH (MODE 'standby_replay', timeout '180s', no_throw);' at
> > C:/gitP/postgres/postgres/src/test/recovery/t/001_stream_rep.pl line 72.
>
> chomp doesn't seem to be working as expected. Are you using Strawberry
> Perl? The documentation states that Strawberry Perl is required for
> Windows builds. Are you using the correct Perl?
>
>
> https://www.postgresql.org/docs/devel/installation-platform-notes.html#WINDOWS-REQUIREMENTS
> > Strawberry Perl is required to run the build generation
> > scripts. MinGW or Cygwin Perl will not work. It must also be present
> > in the PATH. Binaries can be downloaded from
> > https://strawberryperl.com.
>
> Regards,
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
>
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows
2026-06-30 07:37 BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows PG Bug reporting form <[email protected]>
2026-07-01 08:40 ` Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows Kyotaro Horiguchi <[email protected]>
2026-07-13 06:09 ` Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows Karen Huang <[email protected]>
@ 2026-07-13 07:21 ` Karen Huang <[email protected]>
2026-07-13 10:01 ` Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows Nazir Bilal Yavuz <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Karen Huang @ 2026-07-13 07:21 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]
Here is the detailed test log file.
On Mon, Jul 13, 2026 at 2:09 PM Karen Huang <[email protected]>
wrote:
> Yes, we are using the Strawberry Perl. It can be found in CMD like below:
> >where perl
> C:\Strawberry\perl\bin\perl.exe
>
> On Wed, Jul 1, 2026 at 4:40 PM Kyotaro Horiguchi <[email protected]>
> wrote:
>
>> At Tue, 30 Jun 2026 07:37:00 +0000, PG Bug reporting form <
>> [email protected]> wrote in
>> > # die: WAIT FOR LSN failed: error running SQL: 'psql:<stdin>:1: ERROR:
>> > invalid input syntax for type pg_lsn: "0/03045AA0
>> > "
>> > '
>> > # while running 'psql --no-psqlrc --no-align --tuples-only --quiet
>> --dbname
>> > port=30741 host=127.0.0.1 dbname='postgres' --file - --variable
>> > ON_ERROR_STOP=1' with sql 'WAIT FOR LSN '0/03045AA0
>> > ' WITH (MODE 'standby_replay', timeout '180s', no_throw);' at
>> > C:/gitP/postgres/postgres/src/test/recovery/t/001_stream_rep.pl line
>> 72.
>>
>> chomp doesn't seem to be working as expected. Are you using Strawberry
>> Perl? The documentation states that Strawberry Perl is required for
>> Windows builds. Are you using the correct Perl?
>>
>>
>> https://www.postgresql.org/docs/devel/installation-platform-notes.html#WINDOWS-REQUIREMENTS
>> > Strawberry Perl is required to run the build generation
>> > scripts. MinGW or Cygwin Perl will not work. It must also be present
>> > in the PATH. Binaries can be downloaded from
>> > https://strawberryperl.com.
>>
>> Regards,
>>
>> --
>> Kyotaro Horiguchi
>> NTT Open Source Software Center
>>
>
Attachments:
[application/octet-stream] postgresql_test.log (3.8M, ../../CAKLsQevtMj4JNQuqHEk_VyVGb4W2fF1JooN2BYgcd5EMiNpvKQ@mail.gmail.com/3-postgresql_test.log)
download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows
2026-06-30 07:37 BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows PG Bug reporting form <[email protected]>
2026-07-01 08:40 ` Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows Kyotaro Horiguchi <[email protected]>
2026-07-13 06:09 ` Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows Karen Huang <[email protected]>
2026-07-13 07:21 ` Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows Karen Huang <[email protected]>
@ 2026-07-13 10:01 ` Nazir Bilal Yavuz <[email protected]>
0 siblings, 0 replies; 12+ messages in thread
From: Nazir Bilal Yavuz @ 2026-07-13 10:01 UTC (permalink / raw)
To: Karen Huang <[email protected]>; +Cc: Kyotaro Horiguchi <[email protected]>; [email protected]
Hi,
On Mon, 13 Jul 2026 at 11:28, Karen Huang <[email protected]> wrote:
>
> Here is the detailed test log file.
Could you please show which IPC::Run version is installed. I remember
a problem on Windows MinGW [1], which I think is similar to what you
have encountered. I know that 'NJM/IPC-Run-20250809.0' is working as
expected. So, could you please try this version if it is different
from what you have already installed.
[1] https://www.postgresql.org/message-id/CAN55FZ06xanSbJdHe-CurjX_qNuBWZDEvS1kAk36L38YCtZXnw%40mail.gma...
--
Regards,
Nazir Bilal Yavuz
Microsoft
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2026-07-13 10:01 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-03-06 13:51 BUG #18379: LDAP bind password exposed PG Bug reporting form <[email protected]>
2024-03-06 15:40 ` Tom Lane <[email protected]>
2024-03-06 18:40 ` Stephen Frost <[email protected]>
2024-03-06 19:52 ` Tom Lane <[email protected]>
2024-03-07 06:34 ` Stephen Frost <[email protected]>
2024-03-27 07:42 ` Andrew Dunstan <[email protected]>
2024-03-06 15:46 ` Laurenz Albe <[email protected]>
2026-06-30 07:37 BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows PG Bug reporting form <[email protected]>
2026-07-01 08:40 ` Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows Kyotaro Horiguchi <[email protected]>
2026-07-13 06:09 ` Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows Karen Huang <[email protected]>
2026-07-13 07:21 ` Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows Karen Huang <[email protected]>
2026-07-13 10:01 ` Re: BUG #19541: Postgresql failed to run 150+ tests on both debug and release configurations with VS 2026 on Windows Nazir Bilal Yavuz <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox