Re: Tom Lane 2020-01-09 <16328.1578606...@sss.pgh.pa.us>
> build part.) I pushed a patch using SKIP_READLINE_TESTS.
> Christoph should be able to set that for the Ubuntu branches
> where the test is failing.
That "fixed" the problem on xenial, thanks.
Christoph
I wrote:
> Peter Eisentraut writes:
>> I think he means something like
>> make check with_readline=no
>> not for the actual build.
> Oh, I see. I'd rather not codify that though, because it risks
> problems if that symbol ever gets used any other way. I was
> thinking of making the test
Peter Eisentraut writes:
> On 2020-01-09 16:50, Tom Lane wrote:
>> That would disable psql's tab completion, command editing, and history
>> altogether, which I doubt is what you want for production builds.
>> If we conclude we can't work around the testing issues for ancient
>> libedit, probably
On 2020-01-09 16:50, Tom Lane wrote:
Christoph Berg writes:
Fwiw if libedit in xenial is Just Broken and fixing the tests would
just codify the brokenness without adding any value, I'll just disable
that test in that particular build. It looks like setting
with_readline=no on the make command
Christoph Berg writes:
> Fwiw if libedit in xenial is Just Broken and fixing the tests would
> just codify the brokenness without adding any value, I'll just disable
> that test in that particular build. It looks like setting
> with_readline=no on the make command line should work.
That would
Re: Robert Haas 2020-01-09
> > So that raises the question: why does xenial's version of libedit
> > not match either its documentation or the distributed source code?
> > Because it doesn't.
>
> The level of effort you've put into this is extremely impressive, but
> I can't shake the feeling
On Tue, Jan 7, 2020 at 5:29 PM Tom Lane wrote:
> So that raises the question: why does xenial's version of libedit
> not match either its documentation or the distributed source code?
> Because it doesn't.
The level of effort you've put into this is extremely impressive, but
I can't shake the
On Mon, Jan 6, 2020 at 4:26 PM Christoph Berg wrote:
>
> Re: Tom Lane 2020-01-05 <25771.1578249...@sss.pgh.pa.us>
>
> Ubuntu bionic fails elsewhere:
>
> 07:19:51 t/001_stream_rep.pl .. ok
> 07:19:53 t/002_archiving.pl ... ok
> 07:19:59 t/003_recovery_targets.pl
I wrote:
> I installed libedit_3.1-20150325.orig.tar.gz from source here, and it
> passes our current regression test and seems to behave just fine in
> light manual testing. (I did not apply any of the Debian-specific
> patches at [1], but they don't look like they'd explain much.)
> So I'm a
On Tue, Jan 7, 2020 at 12:43 AM Christoph Berg wrote:
>
> Re: Tom Lane 2020-01-06 <3764.1578323...@sss.pgh.pa.us>
> > > Does not work on Ubuntu bionic, xenial. (Others not tested.)
> >
> > Hmm ... do we care? The test output seems to show that xenial's
> > 3.1-20150325-1ubuntu2 libedit is
Christoph Berg writes:
> Re: Tom Lane 2020-01-06 <3764.1578323...@sss.pgh.pa.us>
>>> Does not work on Ubuntu bionic, xenial. (Others not tested.)
>> Hmm ... do we care? The test output seems to show that xenial's
>> 3.1-20150325-1ubuntu2 libedit is completely broken. Maybe there's
>> a way to
Re: Tom Lane 2020-01-06 <3764.1578323...@sss.pgh.pa.us>
> > Does not work on Ubuntu bionic, xenial. (Others not tested.)
>
> Hmm ... do we care? The test output seems to show that xenial's
> 3.1-20150325-1ubuntu2 libedit is completely broken. Maybe there's
> a way to work around that, but it's
Christoph Berg writes:
> I lost track of what bug is supposed to be where, so here's a summary
> of the state at apt.postgresql.org:
> PG13 head work on Debian unstable, buster, stretch.
Cool.
> Does not work on Ubuntu bionic, xenial. (Others not tested.)
Hmm ... do we care? The test output
Re: Tom Lane 2020-01-05 <25771.1578249...@sss.pgh.pa.us>
> The current state of play on this is that I committed a hacky workaround
> [1], but there is now a fix for it in libedit upstream [2][3]. I gather
> from looking at Debian's package page that the fix could be expected to
> propagate to
I wrote:
> Indeed. It appears that recent libedit breaks tab-completion for
> words involving a backslash, which is the fault of this upstream
> commit:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/filecomplete.c.diff?r1=1.52=1.53
> Basically what that's doing is applying de-backslashing
On 5 January 2020 16:38:36 GMT, Tom Lane wrote:
>ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>> Here's one final style cleanup for the TAP test.
>
>LGTM, pushed.
Thanks!
>One minor note: you wanted to change the \DRD test to
>
>+check_completion("\\DRD\t", qr/\\drds
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Here's one final style cleanup for the TAP test.
LGTM, pushed.
One minor note: you wanted to change the \DRD test to
+check_completion("\\DRD\t", qr/\\drds /, "complete \\DRD to \\drds");
but that doesn't work everywhere,
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> Tom Lane writes:
>
>> Cool, I'll go commit a fix along those lines. Thanks for tracing
>> this down!
>
> Here's one final style cleanup for the TAP test.
>
> - use like() for the banner test
> - pass the regexes around as qr// objects, so
Tom Lane writes:
> Cool, I'll go commit a fix along those lines. Thanks for tracing
> this down!
Here's one final style cleanup for the TAP test.
- use like() for the banner test
- pass the regexes around as qr// objects, so they can be
syntax-highlighted properly, and don't need regex
On Sat, Jan 4, 2020 at 6:17 PM Tom Lane wrote:
> Cool, I'll go commit a fix along those lines. Thanks for tracing
> this down!
Glad to help!
--
Peter Geoghegan
Peter Geoghegan writes:
> On Sat, Jan 4, 2020 at 5:57 PM Tom Lane wrote:
>> A quick look at the readline docs suggests that the
>> best way to do that would be to set envar INPUTRC to /dev/null --- could
>> you confirm that that works for you?
> Yes -- "export INPUTRC=/dev/null" also makes it
On Sat, Jan 4, 2020 at 5:57 PM Tom Lane wrote:
> So what we really want here, I guess, is for the test script to suppress
> reading of ~/.inputrc, on the same principle that it suppresses reading
> of ~/.psqlrc.
That was what I thought of, too.
> A quick look at the readline docs suggests that
I wrote:
> Peter Geoghegan writes:
>> Once I comment out the following two lines from ~/.inputrc, everything
>> works fine on
>> HEAD + HEAD-unset-TERM-in-tab-completion-test.patch:
>> set colored-completion-prefix on
>> set colored-stats on
> Hm. I wonder how it is that that leads to ignoring
Peter Geoghegan writes:
> I've found the actual problem -- it's my ~/.inputrc. Which is read in by
> libreadline at some point (determined this using ltrace).
Ah-hah!
So what we really want here, I guess, is for the test script to suppress
reading of ~/.inputrc, on the same principle that it
On Sat, Jan 4, 2020 at 4:14 PM Tom Lane wrote:
> Um, well, that's the same behavior you were seeing before.
> So the terminfo reinstall didn't really do anything.
Sigh.
> I'm still curious about which terminfo file your psql actually
> reads if TERM is unset, and whether that file is visibly
>
Peter Geoghegan writes:
> With the attached patch against HEAD (which is based on your earlier
> unset-TERM-in-tab-completion-test.patch), I find that the tests fail
> as follows:
Um, well, that's the same behavior you were seeing before.
So the terminfo reinstall didn't really do anything.
I'm
On Sat, Jan 4, 2020 at 3:39 PM Tom Lane wrote:
> Hm, well, HEAD still has the hackery with explicit accounting for
> escape sequences. Could you try it with the patch I showed to unset
> TERM and remove that stuff? (It won't apply exactly to HEAD, but
> the diffs are simple enough, or you could
Peter Geoghegan writes:
> Tom just advised me via private e-mail that my termcap database may be
> the issue here. Looks like he was right. I did a "sudo aptitude
> reinstall ncurses-base", and now the tests pass against HEAD. (I
> probably should have tried to preserve things before going ahead
On Sat, Jan 4, 2020 at 12:56 PM Tom Lane wrote:
> Yeah, there is still something unexplained about that. We've so far
> failed to pin the blame on either readline version or environment
> settings ... but what else could be causing you to get different
> results?
Tom just advised me via private
On Sat, Jan 4, 2020 at 12:56 PM Tom Lane wrote:
> Yeah, there is still something unexplained about that. We've so far
> failed to pin the blame on either readline version or environment
> settings ... but what else could be causing you to get different
> results?
Beats me. Could have something
Peter Geoghegan writes:
> FWIW, I find it very surprising that it was possible for the test to
> fail on my workstation/server, without it failing on any buildfarm
> animals.
Yeah, there is still something unexplained about that. We've so far
failed to pin the blame on either readline version
Andrew Dunstan writes:
> On Sun, Jan 5, 2020 at 6:29 AM Tom Lane wrote:
>> What has to have broken those machines was the change to explicitly
>> force TERM to "xterm". Now I'm wondering what their prevailing
>> setting was before that. Maybe it was undef, or some absolutely
>> vanilla thing
On Sat, Jan 4, 2020 at 11:50 AM Tom Lane wrote:
> So we're going to have to make some decisions about what range of
> libedit builds we want to cater for in the tab-completion tests.
> Given that the plan is to considerably increase the coverage of
> those tests, I'm hesitant to promise that
On Sun, Jan 5, 2020 at 6:29 AM Tom Lane wrote:
>
> I wrote:
> > Seeing that you're also having issues with a stack involving
> > libtinfo.so.5, here's my theory: libtinfo version 5 is brain-dead
> > about whether it needs to issue cursor repositioning commands, and
> > tends to do so even when
I wrote:
> Seeing that you're also having issues with a stack involving
> libtinfo.so.5, here's my theory: libtinfo version 5 is brain-dead
> about whether it needs to issue cursor repositioning commands, and
> tends to do so even when the cursor is in the right place already.
> Version 6 fixed
Peter Geoghegan writes:
> On Sat, Jan 4, 2020 at 10:19 AM Tom Lane wrote:
>> Looking closer, I see that your actual output included *both*
>> spaces and escape sequences between the table names, so it
>> needs to be more like the attached.
> This patch makes the tests pass. Thanks!
Ah, good.
On Sat, Jan 4, 2020 at 10:19 AM Tom Lane wrote:
> Looking closer, I see that your actual output included *both*
> spaces and escape sequences between the table names, so it
> needs to be more like the attached.
This patch makes the tests pass. Thanks!
> So now I'm thinking again that there must
I wrote:
> Meh. I must be too tired to get the regexp syntax right.
Looking closer, I see that your actual output included *both*
spaces and escape sequences between the table names, so it
needs to be more like the attached.
Also, I apparently misread the control sequences. What they
look like
On Fri, Jan 3, 2020 at 10:39 PM Tom Lane wrote:
> Hmm. Usually this sort of software gets more weird in newer
> versions, not less so ;-). Still, it's a starting point.
In case I was unclear: I meant to suggest that this may have something
to do with Ubuntu having patched the Debian package
Peter Geoghegan writes:
> On Fri, Jan 3, 2020 at 10:39 PM Tom Lane wrote:
>> Attached is a blind attempt to fix this by allowing escape
>> sequence(s) instead of spaces between the words. Does this
>> work for you?
> I'm afraid not; no apparent change. No change in the "Actual output
> was"
On Fri, Jan 3, 2020 at 10:39 PM Tom Lane wrote:
> Attached is a blind attempt to fix this by allowing escape
> sequence(s) instead of spaces between the words. Does this
> work for you?
I'm afraid not; no apparent change. No change in the "Actual output
was" line, either.
--
Peter Geoghegan
Peter Geoghegan writes:
> On Fri, Jan 3, 2020 at 9:30 PM Tom Lane wrote:
>> BTW, it seems somewhat likely that this is less about libreadline
>> than about its dependency libtinfo. On my machine that's from
>> ii libtinfo6:amd64 6.1+20181013-2+deb10u2
>>
On Fri, Jan 3, 2020 at 9:30 PM Tom Lane wrote:
> BTW, it seems somewhat likely that this is less about libreadline
> than about its dependency libtinfo. On my machine that's from
>
> ii libtinfo6:amd64 6.1+20181013-2+deb10u2
> amd64shared low-level
Peter Geoghegan writes:
> On Fri, Jan 3, 2020 at 7:06 PM Peter Geoghegan wrote:
>> No. Also tried setting PG_COLOR="off" and CLICOLOR=0 -- that also
>> didn't help. (This was based on possibly-relevant vars that "env"
>> showed were set).
Yeah, that's not terribly surprising, because if I'm
On Fri, Jan 3, 2020 at 7:06 PM Peter Geoghegan wrote:
> No. Also tried setting PG_COLOR="off" and CLICOLOR=0 -- that also
> didn't help. (This was based on possibly-relevant vars that "env"
> showed were set).
Removing the single check_completion() test from 010_tab_completion.pl
that actually
On Fri, Jan 3, 2020 at 6:51 PM Tom Lane wrote:
> Hmm. If you set it to plain "xterm", does the test pass?
No. Also tried setting PG_COLOR="off" and CLICOLOR=0 -- that also
didn't help. (This was based on possibly-relevant vars that "env"
showed were set).
--
Peter Geoghegan
Peter Geoghegan writes:
>> I'm curious also what is your prevailing setting
>> of TERM?
> I use zsh, with a fairly customized setup. $TERM is "xterm-256color"
> in the affected shell. (I have a feeling that this has something to do
> with my amazing technicolor terminal.)
Hmm. If you set it
On Fri, Jan 3, 2020 at 6:16 PM Tom Lane wrote:
> Huh. What readline or libedit version are you using, on what
> platform?
Ubuntu 18.04. I used ldd to verify that psql links to the system
libreadline, which is libreadline7:amd64 -- that's what Debian
packages as "7.0-3".
> I'm curious also what
Peter Geoghegan writes:
> Not sure if the specifics matter, but FWIW "make check-world" ended
> with the following failure just now:
> # Failed test 'offer multiple table choices'
> # at t/010_tab_completion.pl line 105.
> # Actual output was "\r\n\e[01;35mmytab\e[0m\e[K123\e[0m\e[K
>
On Fri, Jan 3, 2020 at 9:59 AM Robert Haas wrote:
> I take no position on whether Debian is correct in its assessment of
> such things, but I reiterate my previous opposition to breaking it
> just because we don't agree with it, or because Tom specifically
> doesn't. It's too mainstream a
Christoph Berg writes:
> Re: Tom Lane 2020-01-03 <26339.1578072...@sss.pgh.pa.us>
>> You do? I went looking in the Debian package source repo just the
>> other day for some evidence that that was true, and couldn't find
>> any, so I concluded that it was only an urban legend. Where is that
>>
On Fri, Jan 3, 2020 at 12:48 PM Christoph Berg wrote:
> > Perhaps more importantly, *why* is it done? It seems to me that it
> > takes a pretty fevered imagination to suppose that using libreadline
>
> Tom, claiming that things are "fevered" just because you didn't like
> them is not
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Tom Lane writes:
>> Anybody know an easy way to do that in Perl?
> I was going to suggest using Test::More's like() function to do the
> regex check, but sadly that only escapes things that would break the TAP
> stream
Re: Tom Lane 2020-01-03 <26339.1578072...@sss.pgh.pa.us>
> Christoph Berg writes:
> > Re: Tom Lane 2020-01-03 <13708.1578059...@sss.pgh.pa.us>
> >> I found out while investigating this that the libedit version shipping
> >> with buster (3.1-20181209) is differently broken for the same case:
>
>
Christoph Berg writes:
> Re: Tom Lane 2020-01-03 <13708.1578059...@sss.pgh.pa.us>
>> I found out while investigating this that the libedit version shipping
>> with buster (3.1-20181209) is differently broken for the same case:
> (Fwiw this wasn't spotted before because we have this LD_PRELOAD
Tom Lane writes:
> Also, while I'm asking for Perl advice: I can see in my editor that
> there's a control-G bell character in that string, but this is far
> from obvious on the web page. I'd kind of like to get the report
> to escapify control characters so that what comes out is more like
>
>
Re: Tom Lane 2020-01-03 <13708.1578059...@sss.pgh.pa.us>
> I found out while investigating this that the libedit version shipping
> with buster (3.1-20181209) is differently broken for the same case:
(Fwiw this wasn't spotted before because we have this LD_PRELOAD hack
that replaces libedit with
Christoph Berg writes:
> Shouldn't this print some "expected foo, got bar" diagnostics instead
> of just dying?
BTW, as far as that goes, we do: see for instance the tail end of
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=desmoxytes=2020-01-02%2020%3A04%3A03
ok 8 - offer multiple
Christoph Berg writes:
> Re: Tom Lane 2020-01-02
>> Add basic TAP tests for psql's tab-completion logic.
> The \DRD test fails on Debian/unstable:
Indeed. It appears that recent libedit breaks tab-completion for
words involving a backslash, which is the fault of this upstream
commit:
Re: Tom Lane 2020-01-02
> Add basic TAP tests for psql's tab-completion logic.
The \DRD test fails on Debian/unstable:
# check case-sensitive keyword replacement
# XXX the output here might vary across readline versions
check_completion(
"\\DRD\t",
"\\DRD\b\b\bdrds ",
"complete
60 matches
Mail list logo
