Testing with concurrent sessions
in [PgSql]
|
From: "Kevin Grittner" on 15 Jan 2010 13:36 Markus Wanner <markus(a)bluegap.ch> wrote: > Strangely, your log has escape codes in it, which I'm assuming > makes the parsing choke. Is that something special to your > installation? My psql never colors its outputs... I haven't configured anything like that intentionally. I don't *see* any colors when I use psql. Can you think of anywhere I should check something which might be causing this? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Markus Wanner on 15 Jan 2010 13:51 Hi, Kevin Grittner wrote: > I haven't configured anything like that intentionally. I don't > *see* any colors when I use psql. Can you think of anywhere I > should check something which might be causing this? No idea ATM. However, just to make sure that has absolutely nothing to do with the curses reporter I've written: is that dtester.log you just sent the log from a run with the StreamReporter or the CursesReporter? (Should not have any influence for the log, but you never know). Please recheck with the StreamReporter and try to grep the lines starting with "[psql0]", "[psql1]" and "[psql2]". Dtester simply logs all and any output of all 3rd party processes started. Alternatively, you may want to filter out all lines that start with "[postmaster0]", that might already reduce what we can consider noise in this case. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 15 Jan 2010 13:59 Markus Wanner <markus(a)bluegap.ch> wrote: > Strangely, your log has escape codes in it, which I'm assuming > makes the parsing choke. Is that something special to your > installation? My pager is "less"; could that cause it? Could the twisted environment look like one where the pager should kick in? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Markus Wanner on 15 Jan 2010 14:09 Hi, Kevin Grittner wrote: > My pager is "less"; could that cause it? Could the twisted > environment look like one where the pager should kick in? Yes, that could be it. At least it fails here, too, if I set PAGER=less. Try: PAGER=more make dcheck So, the solution probably lies in adjusting the environment, before starting psql. (Maybe even dropping all existing environment variables for better control of the situation). Will add that for dtester 0.1. (Also note that I plan to move most of what's currently in the patch to the dtester package itself. However, that requires it to be (even more) generic.) Thank you for testing the tester ;-) Regards Markus -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 15 Jan 2010 14:18
Markus Wanner wrote: > Hi, > > Kevin Grittner wrote: >> My pager is "less"; could that cause it? Could the twisted >> environment look like one where the pager should kick in? > > Yes, that could be it. At least it fails here, too, if I set > PAGER=less. Try: > > PAGER=more make dcheck > Surely for automated use you want the psql pager off altogether. "psql --pset pager=off" or some such invocation should do it. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |