Horton

Thread

Commits

  1. Make psql/t/030_pager.pl more robust.

  2. Improve guards against false regex matches in BackgroundPsql.pm.

  3. Fix unsafe pushdown of quals referencing grouping Vars

  4. tests: BackgroundPsql: Fix potential for lost errors on windows

  1. 001_password.pl fails with --without-readline

    Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru> — 2025-10-23T09:47:13Z

    Greetings!

If you configure PostgreSQL with --without-readline, test 
authentication/t/001_password.pl fails due to timeout

This can be reproduced on any branch that contains commit 8b886a4 (so, 
on PostgreSQL 13-19)

I've looked through debug info using IPCRUNDEBUG = "data" or "details"

Here's some output:

This is with readline:
     [18:31:45.030](0.027s) ok 22 - scram_iterations in server side ROLE
     IPC::Run 0001 [#15(253566)]: ** pumping
     IPC::Run 0001 [#15(253566)]: write( 10, '\echo background_psql: 
ready
     IPC::Run 0001 [#15(253566)]: \warn background_psql: ready
     IPC::Run 0001 [#15(253566)]: ' ) = 58
     IPC::Run 0001 [#15(253566)]: ** pumping
     IPC::Run 0001 [#15(253566)]: read( 10 ) = 60 chars '\echo 
background_psql: ready
     IPC::Run 0001 [#15(253566)]: \warn background_psql: ready
     IPC::Run 0001 [#15(253566)]: '
     IPC::Run 0001 [#15(253566)]: ** pumping
     IPC::Run 0001 [#15(253566)]: read( 10 ) = 41 chars 'psql (19devel)
     IPC::Run 0001 [#15(253566)]: Type "help" for help.
     IPC::Run 0001 [#15(253566)]:
     IPC::Run 0001 [#15(253566)]: '
     IPC::Run 0001 [#15(253566)]: ** pumping
     IPC::Run 0001 [#15(253566)]: read( 10 ) = 11 chars 'postgres=# '
     IPC::Run 0001 [#15(253566)]: ** pumping
     IPC::Run 0001 [#15(253566)]: read( 10 ) = 65 chars '\echo 
background_psql: ready
     IPC::Run 0001 [#15(253566)]: background_psql: ready
     IPC::Run 0001 [#15(253566)]: postgres=# '
     IPC::Run 0001 [#15(253566)]: ** pumping
     IPC::Run 0001 [#15(253566)]: read( 10 ) = 41 chars '\warn 
background_psql: ready
     IPC::Run 0001 [#15(253566)]: postgres=# '
     IPC::Run 0001 [#15(253566)]: read( 12 ) = 23 chars 'background_psql: 
ready
     IPC::Run 0001 [#15(253566)]: '
     [18:31:45.042](0.013s) # connect output:

And this is without readline:
     [18:34:32.050](0.029s) ok 22 - scram_iterations in server side ROLE
     IPC::Run 0001 [#15(263802)]: ** pumping
     IPC::Run 0001 [#15(263802)]: write( 10, '\echo background_psql: 
ready
     IPC::Run 0001 [#15(263802)]: \warn background_psql: ready
     IPC::Run 0001 [#15(263802)]: ' ) = 58
     IPC::Run 0001 [#15(263802)]: ** pumping
     IPC::Run 0001 [#15(263802)]: read( 10 ) = 60 chars '\echo 
background_psql: ready
     IPC::Run 0001 [#15(263802)]: \warn background_psql: ready
     IPC::Run 0001 [#15(263802)]: '
     IPC::Run 0001 [#15(263802)]: ** pumping
     IPC::Run 0001 [#15(263802)]: read( 10 ) = 98 chars 'psql (19devel)
     IPC::Run 0001 [#15(263802)]: Type "help" for help.
     IPC::Run 0001 [#15(263802)]:
     IPC::Run 0001 [#15(263802)]: postgres=# background_psql: ready
     IPC::Run 0001 [#15(263802)]: postgres=# postgres=# '
     IPC::Run 0001 [#15(263802)]: ** pumping
     IPC::Run 0001 [#15(263802)]: read( 12 ) = 23 chars 'background_psql: 
ready
     IPC::Run 0001 [#15(263802)]: '
     IPC::Run 0001 [#15(263802)]: ** pumping

As you can see, those outputs are different

1) In readline output commands \echo and \warn are re-read (that's why 
banner_match in BackgroundPsql.pm has checks for \n or start of line), 
but in no-readline output both \echo and \warn are read only once, when 
they are first send to psql

2) In readline ouput stdout is re-read multiple times, and banner 
(background_psql: ready) is placed neatly on it's own line, while in 
no-readline output banner in stdout is mixed with "postgres=#" prompts, 
and they are read as one batch

Those differences are probably an effect of inner workings of readline, 
turning input echoing off.

Also, without readline, stdout during query exectution can look like 
this
     # \\echo background_psql: QUERY_SEPARATOR 1:
     # \\warn background_psql: QUERY_SEPARATOR 1:
     # SET
     # postgres=# postgres=# background_psql: QUERY_SEPARATOR 1:
     # postgres=# '

So, there are some ways to handle this situation

1) Skip this test if Postgres is configured without readline support. I 
don't think this is a good way, since this test doesn't really test 
anything that needs readline to work

2) Modify variable banner_match depending on having readline or not. 
Something like the attached

I'm interested to hear your thoughts on this

Oleg Tselebrovskiy, PostgresPro

  2. Re: 001_password.pl fails with --without-readline

    Soumya S Murali <soumyamurali.work@gmail.com> — 2026-01-02T10:09:40Z

    Hi,

I reapplied the patch and tested the patch with (enable-tap-tests +
readline and enable-tap-tests + without-readline). I think the issue
was caused by differences in how psql emits prompts and echoed output
without readline which could lead to banner interleaving, timeouts or
premature TAP termination. In my patch I included the fixes that make
banner detection in BackgroundPsql.pm to be tolerant while keeping
strict line-based cleanup to preserve correct TAP behavior. The fix is
behavior-based and does not rely on configuration variables or test
skipping.
Kindly review my patch attached herewith and please let me know the feedback.

Regards
Soumya

  3. Re: 001_password.pl fails with --without-readline

    Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru> — 2026-01-14T08:32:34Z

    Thanks for your patch!

I like your behaviour-based approach more, but I have some questions
about the patch itself

1) There is a comment in query() function:
# We need to match for the newline, because we try to remove it below, 
and
# it's possible to consume just the input *without* the newline. In
# interactive psql we emit \r\n, so we need to allow for that. Also need
# to be careful that we don't e.g. match the echoed \echo command, 
rather
# than its output.

So, originally, checking that the banner is on it's own line is needed
to distiguish \echo $banner and \warn $banner from their output.

It seems that your patch does not distingush them all the time

(taken from query() function with your patch applied)
	my $banner_detect_stdout = qr/\Q$banner\E/;
	my $banner_detect_stderr = qr/(^|\n)\Q$banner\E\r?\n/;

Why do you check stderr for newline but not the stdout?

2) Why did you add /Q/E around the $banner variable? It doesn't
contain any regex metacharacters (in query() function there is
$query_cnt inside of $banner, but it should be substituted by Perl).
Maybe it is really necessary and I just don't get it

-----

While testing and checking, I've made a new patch. It's very
simple and it just checks that there is banner in a string, but
the string doesn't start with \echo or \warn

Maybe it needs some additional comments, but lets decide on which
approach to use

-----

There is also a problem of test src/bin/psql/t/030_pager.pl - it
just doesn't work with --without-readline, all regexes seem to be right
and debug output shows correct data. None of our patches
currently solve it, I'll look into it

-----

Regards,
Oleg

  4. Re: 001_password.pl fails with --without-readline

    Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru> — 2026-01-14T10:11:11Z

    The easiest way to fix 030_pager.pl is to just replace ' ' with '*'
in regex. With readline, everything that we look for is placed on
its own line so we don't break anything, but --without-readline
produces the following output (with some hand-written debug info):

	IPC::Run 0000 [#2(438962)]: ** pumping
	IPC::Run 0000 [#2(438962)]: read( 11 ) = 4 chars '39
	IPC::Run 0000 [#2(438962)]: '

	stream:postgres=# \pset expanded
	SELECT generate_series(1,20) as g;
	Expanded display is on.
	postgres=# 39

So the output that is turned on with IPCRUNDEBUG=data shows us "we got
only 4 chars, '39\n\0'!", but in reality we have more stuff in stream,
so pump_until() function doesn't match with passed regex

Patch is attached

Regards,
Oleg

  5. Re: 001_password.pl fails with --without-readline

    Soumya S Murali <soumyamurali.work@gmail.com> — 2026-01-16T06:35:44Z

    Hi all,

Thanks for the detailed review and for sharing the updated patches.

> 1) There is a comment in query() function:
> # We need to match for the newline, because we try to remove it below,
> and
> # it's possible to consume just the input *without* the newline. In
> # interactive psql we emit \r\n, so we need to allow for that. Also need
> # to be careful that we don't e.g. match the echoed \echo command,
> rather
> # than its output.
>
> So, originally, checking that the banner is on it's own line is needed
> to distiguish \echo $banner and \warn $banner from their output.
>
> It seems that your patch does not distingush them all the time
>
> (taken from query() function with your patch applied)
>         my $banner_detect_stdout = qr/\Q$banner\E/;
>         my $banner_detect_stderr = qr/(^|\n)\Q$banner\E\r?\n/;
>
> Why do you check stderr for newline but not the stdout?
>

I agree that the original intent of requiring the banner to be on its
own line was to distinguish the output of \echo / \warn from the
echoed commands themselves. In without-readline builds, stdout
buffering can merge prompts and echoed output into a single chunk,
which makes line-anchored matching unreliable there. Stderr, on the
other hand, continues to emit the banner cleanly on its own line, so
keeping it line-based remains reliable. That was the motivation for
relaxing stdout detection while preserving stricter handling on
stderr.

> 2) Why did you add /Q/E around the $banner variable? It doesn't
> contain any regex metacharacters (in query() function there is
> $query_cnt inside of $banner, but it should be substituted by Perl).
> Maybe it is really necessary and I just don't get it
>

This was mainly a defensive choice to ensure the banner is always
treated as a literal string and to avoid any accidental regex
interpretation if the banner format changes in the future. If you feel
this is unnecessary here, I am fine with simplifying it.

>
> While testing and checking, I've made a new patch. It's very
> simple and it just checks that there is banner in a string, but
> the string doesn't start with \echo or \warn
>
> Maybe it needs some additional comments, but lets decide on which
> approach to use
>

I reviewed the patch and agree that it preserves the original intent
more directly and provides a clean way to avoid false matches. I
tested the patch on a clean master branch with and without readline
and from my testing it behaves correctly in both configurations
without introducing TAP synchronization issues or regressions.

> The easiest way to fix 030_pager.pl is to just replace ' ' with '*'
> in regex. With readline, everything that we look for is placed on
> its own line so we don't break anything, but --without-readline
> produces the following output (with some hand-written debug info):
>
>         IPC::Run 0000 [#2(438962)]: ** pumping
>         IPC::Run 0000 [#2(438962)]: read( 11 ) = 4 chars '39
>         IPC::Run 0000 [#2(438962)]: '
>
>         stream:postgres=# \pset expanded
>         SELECT generate_series(1,20) as g;
>         Expanded display is on.
>         postgres=# 39
>
> So the output that is turned on with IPCRUNDEBUG=data shows us "we got
> only 4 chars, '39\n\0'!", but in reality we have more stuff in stream,
> so pump_until() function doesn't match with passed regex
>

Regarding 030_pager.pl, thank you for flagging this. I understand this
is a separate issue and I agree it should be handled independently. I
have tested the patch independently by running psql TAP tests in a
--without-readline build with IPCRUNDEBUG=data enabled via make psql
check. While the debug output is largely suppressed when tests pass,
the behavior described by the patch is
consistent with IPC::Run’s incremental read and the test passes
reliably only after relaxing the regex to tolerate fragmented
output. I think this confirms the correctness of the fix. Also tested
with readline enabled, all psql tests continue to pass cleanly and I
did not observe any regressions.
Overall based on the testing, both patches behave correctly in
readline and non-readline builds and address the respective issues
reliably.
Thank you for working on these and please let me know if you would
like me to test any additional scenarios or branches.


Regards,
Soumya

  6. Re: 001_password.pl fails with --without-readline

    Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru> — 2026-01-16T07:23:11Z

    Thanks for your answer!
 
Personally, I can’t think of any more test scenarios that could be
tested here (maybe some versions of readline library on some exotic
OS could break, but that seems a little far fetched), so, if you see
no further problems with the patches, you could change
the commitfest entry status to "Ready for Committer", so we could get
another opinion on patches and, if possible, get them committed.
 
--
Regards,
Oleg

  7. Re: 001_password.pl fails with --without-readline

    Soumya S Murali <soumyamurali.work@gmail.com> — 2026-01-16T10:29:19Z

    Hi,

On Fri, Jan 16, 2026 at 12:53 PM Oleg Tselebrovskiy
<o.tselebrovskiy@postgrespro.ru> wrote:
>
> Thanks for your answer!
>
> Personally, I can’t think of any more test scenarios that could be
> tested here (maybe some versions of readline library on some exotic
> OS could break, but that seems a little far fetched), so, if you see
> no further problems with the patches, you could change
> the commitfest entry status to "Ready for Committer", so we could get
> another opinion on patches and, if possible, get them committed.
>

Thank you for the clarification.
The patches seem correct based on the testing I have done so far and
for me I did not observe any further issues in both readline and
non-readline configurations. Since I am one of the reviewers and not
the only one. I consider my review as only one data point and I would
feel more comfortable if the patches also receive input from other
reviewers who may have more experience with this part of the code or
different testing environments.
I am happy to add my test results and observations to the CommitFest
entry to assist further review. Once others have had a chance to look
and review, it would likely be more appropriate to move the entry
forward.


Regards,
Soumya

  8. Re: 001_password.pl fails with --without-readline

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-16T22:46:51Z

    Soumya S Murali <soumyamurali.work@gmail.com> writes:
> The patches seem correct based on the testing I have done so far and
> for me I did not observe any further issues in both readline and
> non-readline configurations. Since I am one of the reviewers and not
> the only one. I consider my review as only one data point and I would
> feel more comfortable if the patches also receive input from other
> reviewers who may have more experience with this part of the code or
> different testing environments.

Well, there aren't any other reviewers listed in the CF entry, so
you need to have more faith in yourself ;-).

However, I looked at these patches and I feel like they are not doing
enough to be proof against false matches, or false non-matches, due to
variations in readline (or no-readline) behavior.

The fundamental issue in 0001 is how do we avoid matching to the echo
of the \echo or \warn command rather than the output we want to see?
Oleg's patch assumes it's okay if there's not "\echo" or "\warn" just
ahead of the banner, but I doubt that's good enough.  Insertion of a
prompt, for example, could allow a false match.  I think we can
make the test far more robust if we rely on psql's ability to do a
little computation instead of only echoing the command string verbatim.
There are various ways that could be done, but what I propose in the
attached v3 is to break the banner into two psql variables, like so:
	\set part1 something
	\set part2 else
	\echo :part1 :part2
Then, if we match for "something else", there is no possibility
whatsoever that that will match echoed commands, only the real
output of the \echo.

While debugging that I got annoyed that a match failure results
in a timeout exit with absolutely no data logged about what output
the test got.  So v3-0001 also changes timeout() --- which creates
a timeout that aborts the test --- to timer() --- which does what
the test author clearly expected, namely just stop waiting for
more input.  (There's a thread somewhere around here about making
that change more globally, but I went ahead and did it here.)

As for 0002, I agree that we can't do much except not insist that
the match cover the whole line.  However, then the question is how
much risk are we taking of a false match?  It's not too bad for the
first three tests, where we know what the query will output so we
can be sure that the pattern will (or won't) appear if the pager
is or isn't invoked.  However, testing for just "\d+\n" seems fairly
scary from that standpoint.  It happens not to match to the current
contents of information_schema.referential_constraints, but that's
a very hairy query that's subject to change.  I think we had better
take this test out of the business of relying on the contents of that
view, and instead create our own simple view that we can be sure of.

On a more nitpicky level, writing "^.*" is useless, because it'll
match anything at all, so we might as well just remove it from the
pattern.

So I arrive at the v3 patches attached.  Any thoughts?

			regards, tom lane

  9. Re: 001_password.pl fails with --without-readline

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-17T00:19:38Z

    I wrote:
> There are various ways that could be done, but what I propose in the
> attached v3 is to break the banner into two psql variables, like so:
> 	\set part1 something
> 	\set part2 else
> 	\echo :part1 :part2
> Then, if we match for "something else", there is no possibility
> whatsoever that that will match echoed commands, only the real
> output of the \echo.

On second thought, that's far more complicated than necessary.
It should be sufficient to insert quote marks in the echo commands.

			regards, tom lane

  10. Re: 001_password.pl fails with --without-readline

    Soumya S Murali <soumyamurali.work@gmail.com> — 2026-01-19T07:32:56Z

    Hi all,

Thank you for the detailed review.

> Well, there aren't any other reviewers listed in the CF entry, so
> you need to have more faith in yourself ;-).
>
> However, I looked at these patches and I feel like they are not doing
> enough to be proof against false matches, or false non-matches, due to
> variations in readline (or no-readline) behavior.
>
> The fundamental issue in 0001 is how do we avoid matching to the echo
> of the \echo or \warn command rather than the output we want to see?
> Oleg's patch assumes it's okay if there's not "\echo" or "\warn" just
> ahead of the banner, but I doubt that's good enough.  Insertion of a
> prompt, for example, could allow a false match.  I think we can
> make the test far more robust if we rely on psql's ability to do a
> little computation instead of only echoing the command string verbatim.
> There are various ways that could be done, but what I propose in the
> attached v3 is to break the banner into two psql variables, like so:
>         \set part1 something
>         \set part2 else
>         \echo :part1 :part2
> Then, if we match for "something else", there is no possibility
> whatsoever that that will match echoed commands, only the real
> output of the \echo.
>
> While debugging that I got annoyed that a match failure results
> in a timeout exit with absolutely no data logged about what output
> the test got.  So v3-0001 also changes timeout() --- which creates
> a timeout that aborts the test --- to timer() --- which does what
> the test author clearly expected, namely just stop waiting for
> more input.  (There's a thread somewhere around here about making
> that change more globally, but I went ahead and did it here.)
>
> As for 0002, I agree that we can't do much except not insist that
> the match cover the whole line.  However, then the question is how
> much risk are we taking of a false match?  It's not too bad for the
> first three tests, where we know what the query will output so we
> can be sure that the pattern will (or won't) appear if the pager
> is or isn't invoked.  However, testing for just "\d+\n" seems fairly
> scary from that standpoint.  It happens not to match to the current
> contents of information_schema.referential_constraints, but that's
> a very hairy query that's subject to change.  I think we had better
> take this test out of the business of relying on the contents of that
> view, and instead create our own simple view that we can be sure of.
>
> On a more nitpicky level, writing "^.*" is useless, because it'll
> match anything at all, so we might as well just remove it from the
> pattern.
>
> So I arrive at the v3 patches attached.  Any thoughts?

I understand the concerns raised and agree that relying purely on
relaxed regex matching creates room for false matches if prompts or
other output get interleaved. Also agree that leveraging psql
semantics to make such matches impossible is a much stronger approach.
The change from timeout() to timer() seems to give better visibility
into partial output on failure and will make testing far easier to
diagnose.
For 030_pager.pl, I agree that relaxing the match is necessary for
no-readline builds, but for that we should avoid depending on fragile
catalog contents making the test self-contained with a controlled
query or view which sounds like the right direction to reduce
long-term risk.

> I wrote:
> > There are various ways that could be done, but what I propose in the
> > attached v3 is to break the banner into two psql variables, like so:
> >       \set part1 something
> >       \set part2 else
> >       \echo :part1 :part2
> > Then, if we match for "something else", there is no possibility
> > whatsoever that that will match echoed commands, only the real
> > output of the \echo.
>
> On second thought, that's far more complicated than necessary.
> It should be sufficient to insert quote marks in the echo commands.

I tried applying both the v3 and v4 patches on a clean branch tree
reset to the current origin/master, but neither of them applied
cleanly due to context mismatches in BackgroundPsql.pm and
030_pager.pl. I think the patches need rebasing on the current master
before they can be tested further. I will be happy to re-test once
rebased patches are available.


Regards,
Soumya

  11. Re: 001_password.pl fails with --without-readline

    Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru> — 2026-01-19T08:37:39Z

    Answering both emails at once

-----
BackgroundPsql.pm

> While debugging that I got annoyed that a match failure results
> in a timeout exit with absolutely no data logged about what output
> the test got.  So v3-0001 also changes timeout() --- which creates
> a timeout that aborts the test --- to timer() --- which does what
> the test author clearly expected, namely just stop waiting for
> more input.  (There's a thread somewhere around here about making
> that change more globally, but I went ahead and did it here.)

I've found your thread about this - [1], and I agree, using
timer() is better here, we get the stdout and stderr of a timed-out
query

> On second thought, that's far more complicated than necessary.
> It should be sufficient to insert quote marks in the echo commands.

Quote marks really work! Very elegant change, it works with or without
readline - I like it! v3 approach with \set was good too, but I too
prefer quote marks

Also, thanks for making both "pump until" blocks identical, it seemed
a little strange to have them be different. At first I thought it was
made deliberately, but when I was debugging pump_until function I saw
how two streams were filling and it seems that both "pump until"
blocks work the same way

-----
030_pager.pl

> As for 0002, I agree that we can't do much except not insist that
> the match cover the whole line.  However, then the question is how
> much risk are we taking of a false match?  It's not too bad for the
> first three tests, where we know what the query will output so we
> can be sure that the pattern will (or won't) appear if the pager
> is or isn't invoked.  However, testing for just "\d+\n" seems fairly
> scary from that standpoint.  It happens not to match to the current
> contents of information_schema.referential_constraints, but that's
> a very hairy query that's subject to change.  I think we had better
> take this test out of the business of relying on the contents of that
> view, and instead create our own simple view that we can be sure of.

I like the idea of using a hand-crafted view for the test instead of
information_schema.referential_constraints, since its d+ output can
change between PostgreSQL versions, and hand-crafted view won't change
suddenly, only deliberately

> On a more nitpicky level, writing "^.*" is useless, because it'll
> match anything at all, so we might as well just remove it from the
> pattern.

Well, yeah, there's no difference between "^.*39" and just plain "39"
for such a regex

All in all - v4 seems to be both elegant and robust

[1] - https://www.postgresql.org/message-id/1100715.1712265845@sss.pgh.pa.us
 
--
Regards,
Oleg

  12. Re: 001_password.pl fails with --without-readline

    Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru> — 2026-01-19T08:44:45Z

    > I tried applying both the v3 and v4 patches on a clean branch tree
> reset to the current origin/master, but neither of them applied
> cleanly due to context mismatches in BackgroundPsql.pm and
> 030_pager.pl. I think the patches need rebasing on the current master
> before they can be tested further. I will be happy to re-test once
> rebased patches are available.

Just applied both v3 and v4 onto 34740b9 with no conflicts. I don’t
see any commits that touch 030_pager.pl and BackgroundPsql.pm
last few days, so maybe you still have your code changes from
v1 or v2, or something from debugging v3 or v4? I see that you
specified clean code tree, but for me both v3 and v4 applied with
no trouble
 
--
Regards,
Oleg
 
 

  13. Re: 001_password.pl fails with --without-readline

    Soumya S Murali <soumyamurali.work@gmail.com> — 2026-01-19T09:34:47Z

    Hi all,


On Mon, Jan 19, 2026 at 2:15 PM Oleg Tselebrovskiy
<o.tselebrovskiy@postgrespro.ru> wrote:
>
> > I tried applying both the v3 and v4 patches on a clean branch tree
> > reset to the current origin/master, but neither of them applied
> > cleanly due to context mismatches in BackgroundPsql.pm and
> > 030_pager.pl. I think the patches need rebasing on the current master
> > before they can be tested further. I will be happy to re-test once
> > rebased patches are available.
>
> Just applied both v3 and v4 onto 34740b9 with no conflicts. I don’t
> see any commits that touch 030_pager.pl and BackgroundPsql.pm
> last few days, so maybe you still have your code changes from
> v1 or v2, or something from debugging v3 or v4? I see that you
> specified clean code tree, but for me both v3 and v4 applied with
> no trouble
>

Thank you for the guidance.
I fetched all refs and tags locally and reset my tree to a clean
origin/master, but I am unable to locate commit 34740b9 in my
repository, so I assume it may be a local or abbreviated hash. On a
fresh branch, both v3 and v4 patches failed to apply cleanly which
suggests a base mismatch rather than an issue with the patches
themselves.
Could you please share the full commit hash or branch that these
patches are based on? I will be happy to apply them again and re-run
the full test coverage once it is available.

Regards,
Soumya

  14. Re: 001_password.pl fails with --without-readline

    Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru> — 2026-01-19T09:45:07Z

    > Could you please share the full commit hash or branch that these
> patches are based on? I will be happy to apply them again and re-run
> the full test coverage once it is available.
 
The full commit hash is 34740b90bc123d645a3a71231b765b778bdcf049,
it’s the latest commit in repository on github, master branch, see [1]

> I fetched all refs and tags locally and reset my tree to a clean
> origin/master, but I am unable to locate commit 34740b9 in my
> repository

Maybe your origin is out-of-date or is just different?
What does ‘​git remote get-url origin’ say in your local repository?

[1]  https://github.com/postgres/postgres/commits/master/
--
Regards,
Oleg
 

  15. Re: 001_password.pl fails with --without-readline

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-19T18:56:49Z

    =?UTF-8?B?T2xlZyBUc2VsZWJyb3Zza2l5?= <o.tselebrovskiy@postgrespro.ru> writes:
>> I fetched all refs and tags locally and reset my tree to a clean
>> origin/master, but I am unable to locate commit 34740b9 in my
>> repository

> Maybe your origin is out-of-date or is just different?
> What does ‘​git remote get-url origin’ say in your local repository?

34740b9 is there for me, but it's less than a day old:

commit 34740b90bc123d645a3a71231b765b778bdcf049
Author: Richard Guo <rguo@postgresql.org>
Date:   Mon Jan 19 11:13:23 2026 +0900

    Fix unsafe pushdown of quals referencing grouping Vars

However, none of these patches are touching any recently-modified
code AFAIK, so they should apply cleanly even to a slightly out
of date tree.  I suspect Soumya's failure-to-apply problem has
a different cause.  The patches I posted were just "git diff"
output, without a commit message, so I believe you can't use
"git am" to apply them.  Hoary old "patch -p1" ought to work
though.

			regards, tom lane

  16. Re: 001_password.pl fails with --without-readline

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-19T19:01:31Z

    =?UTF-8?B?T2xlZyBUc2VsZWJyb3Zza2l5?= <o.tselebrovskiy@postgrespro.ru> writes:
>> While debugging that I got annoyed that a match failure results
>> in a timeout exit with absolutely no data logged about what output
>> the test got.  So v3-0001 also changes timeout() --- which creates
>> a timeout that aborts the test --- to timer() --- which does what
>> the test author clearly expected, namely just stop waiting for
>> more input.  (There's a thread somewhere around here about making
>> that change more globally, but I went ahead and did it here.)

> I've found your thread about this - [1], and I agree, using
> timer() is better here, we get the stdout and stderr of a timed-out
> query

Thanks for digging that up.  After re-reading that thread I'm feeling
nervous about changing timeout() to timer() in something we need to
back-patch, so I'll leave that change out of the committed patch.
We ought to raise the priority of making that happen, though.

> Also, thanks for making both "pump until" blocks identical, it seemed
> a little strange to have them be different.

Yeah, I couldn't see a reason for that either.

			regards, tom lane

  17. Re: 001_password.pl fails with --without-readline

    Soumya S Murali <soumyamurali.work@gmail.com> — 2026-01-20T06:55:53Z

    Hi all,

Thank you for confirming the full commit hash.

On Mon, Jan 19, 2026 at 3:16 PM Oleg Tselebrovskiy
<o.tselebrovskiy@postgrespro.ru> wrote:
>
> > Could you please share the full commit hash or branch that these
> > patches are based on? I will be happy to apply them again and re-run
> > the full test coverage once it is available.
>
> The full commit hash is 34740b90bc123d645a3a71231b765b778bdcf049,
> it’s the latest commit in repository on github, master branch, see [1]
>
> > I fetched all refs and tags locally and reset my tree to a clean
> > origin/master, but I am unable to locate commit 34740b9 in my
> > repository
>
> Maybe your origin is out-of-date or is just different?
> What does ‘git remote get-url origin’ say in your local repository?

My local workflow uses a fork repository for convenience, but the
origin is the official PostgreSQL repository. I reset my tree to
34740b90bc123d645a3a71231b765b778bdcf049 commit as per suggested and
have fetched all refs. But still I am unable to apply both v3 and v4
patches cleanly on that commit. Every time it fails with context
mismatches in BackgroundPsql.pm (around line 100), even on a clean
working tree.

error: patch failed: src/test/perl/PostgreSQL/Test/BackgroundPsql.pm:100
error: src/test/perl/PostgreSQL/Test/BackgroundPsql.pm: patch does not apply
error: patch failed: src/bin/psql/t/030_pager.pl:40
error: src/bin/psql/t/030_pager.pl: patch does not apply

Anyway I am trying it and will let you know the status once I complete
applying and testing the patches.


Regards,
Soumya

  18. Re: 001_password.pl fails with --without-readline

    Soumya S Murali <soumyamurali.work@gmail.com> — 2026-01-20T07:25:35Z

    Hi all,

Thank you for the guidance and clarifications.

> =?UTF-8?B?T2xlZyBUc2VsZWJyb3Zza2l5?= <o.tselebrovskiy@postgrespro.ru> writes:
> >> I fetched all refs and tags locally and reset my tree to a clean
> >> origin/master, but I am unable to locate commit 34740b9 in my
> >> repository
>
> > Maybe your origin is out-of-date or is just different?
> > What does ‘git remote get-url origin’ say in your local repository?
>
> 34740b9 is there for me, but it's less than a day old:
>
> commit 34740b90bc123d645a3a71231b765b778bdcf049
> Author: Richard Guo <rguo@postgresql.org>
> Date:   Mon Jan 19 11:13:23 2026 +0900
>
>     Fix unsafe pushdown of quals referencing grouping Vars
>
> However, none of these patches are touching any recently-modified
> code AFAIK, so they should apply cleanly even to a slightly out
> of date tree.  I suspect Soumya's failure-to-apply problem has
> a different cause.  The patches I posted were just "git diff"
> output, without a commit message, so I believe you can't use
> "git am" to apply them.  Hoary old "patch -p1" ought to work
> though.

I missed the fact that the patches were raw git diff outputs rather
than meant for git am. I will retry applying them on a clean upstream
master tree and re-run the relevant test suites.

> =?UTF-8?B?T2xlZyBUc2VsZWJyb3Zza2l5?= <o.tselebrovskiy@postgrespro.ru> writes:
> >> While debugging that I got annoyed that a match failure results
> >> in a timeout exit with absolutely no data logged about what output
> >> the test got.  So v3-0001 also changes timeout() --- which creates
> >> a timeout that aborts the test --- to timer() --- which does what
> >> the test author clearly expected, namely just stop waiting for
> >> more input.  (There's a thread somewhere around here about making
> >> that change more globally, but I went ahead and did it here.)
>
> > I've found your thread about this - [1], and I agree, using
> > timer() is better here, we get the stdout and stderr of a timed-out
> > query
>
> Thanks for digging that up.  After re-reading that thread I'm feeling
> nervous about changing timeout() to timer() in something we need to
> back-patch, so I'll leave that change out of the committed patch.
> We ought to raise the priority of making that happen, though.
>
> > Also, thanks for making both "pump until" blocks identical, it seemed
> > a little strange to have them be different.
>
> Yeah, I couldn't see a reason for that either.

I too agree that changing the behavior in a back-patch could be risky
and it makes sense to leave that part out for now while still
addressing the core test robustness issues. I will follow up once I
have re-applied the patches and completed testing.

Regards,
Soumya

  19. Re: 001_password.pl fails with --without-readline

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-01-30T20:13:47Z

    Soumya S Murali <soumyamurali.work@gmail.com> writes:
> I too agree that changing the behavior in a back-patch could be risky
> and it makes sense to leave that part out for now while still
> addressing the core test robustness issues. I will follow up once I
> have re-applied the patches and completed testing.

Since we're reaching the end of the January commitfest,
I went ahead and pushed these patches.  There's still time to
revise them if your testing uncovers anything undesirable.

			regards, tom lane

  20. Re: 001_password.pl fails with --without-readline

    Soumya S Murali <soumyamurali.work@gmail.com> — 2026-02-03T05:42:11Z

    Hi all,


On Sat, Jan 31, 2026 at 1:43 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Soumya S Murali <soumyamurali.work@gmail.com> writes:
> > I too agree that changing the behavior in a back-patch could be risky
> > and it makes sense to leave that part out for now while still
> > addressing the core test robustness issues. I will follow up once I
> > have re-applied the patches and completed testing.
>
> Since we're reaching the end of the January commitfest,
> I went ahead and pushed these patches.  There's still time to
> revise them if your testing uncovers anything undesirable.


Thank you for the update and for pushing the patches.
I will continue testing on the committed code in both readline and
non-readline configurations and will report back if I notice any
unexpected behavior or regressions.

Regards,
Soumya

  21. Re: 001_password.pl fails with --without-readline

    Soumya S Murali <soumyamurali.work@gmail.com> — 2026-02-03T07:24:48Z

    Hi all,

I verified the committed fixes on upstream master by running the tests
with and without readline support and confirmed that the tests passed
successfully in both configurations, validating robustness
improvements to BackgroundPsql and pager tests.

Regards,
Soumya