pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedFailure in commit_ts tap tests
28+ messages / 6 participants
[nested] [flat]
Commits from this thread:
2017-01-26 331f8c311b 56b42a3341 7fb29ea9c6 Remove test for COMMENT ON DATABASE
2017-01-20 a600ee9e3f tests: Use the right Perl operator
* Failure in commit_ts tap tests
@ 2017-01-20 17:23 Pavan Deolasee <pavan.deolasee@gmail.com>
0 siblings, 3 replies; 28+ messages in thread
From: Pavan Deolasee @ 2017-01-20 17:23 UTC (permalink / raw)
To: pgsql-hackers
I see a consistent failure while running "make -C
src/test/modules/commit_ts/ check" on a server compiled with
--enable-tap-tests. This is on the master branch (193a7d791)
t/004_restart.pl ....
1..16
ok 1 - getting ts of InvalidTransactionId reports error
ok 2 - expected error from InvalidTransactionId
ok 3 - getting ts of BootstrapTransactionId succeeds
ok 4 - timestamp of BootstrapTransactionId is null
ok 5 - getting ts of FrozenTransactionId succeeds
ok 6 - timestamp of FrozenTransactionId is null
ok 7 - committs for FirstNormalTransactionId is null
not ok 8 - commit timestamp recorded
Upon investigating logs, I see that perl complains about using != operator
on non-numeric argument.
Argument "" isn't numeric in numeric ne (!=) at t/004_restart.pl line 57.
Argument "Fri Jan 20 07:59:52.322811 2017 PST" isn't numeric in numeric ne
(!=) at t/004_restart.pl line 57.
not ok 8 - commit timestamp recorded
Changing the operator to "ne" works for me (patch attached). But I wonder
if this is something specific to my system? Am I using a wrong/stale
version on OSX Sierra? I'm surprised nobody reported this problem earlier.
$ perl -v
This is perl 5, version 18, subversion 2 (v5.18.2) built for
darwin-thread-multi-2level
(with 2 registered patches, see perl -V for more detail)
Copyright 1987-2013, Larry Wall
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
commit_ts_taptest.patch (application/octet-stream, 590B) download
diff --git a/src/test/modules/commit_ts/t/004_restart.pl b/src/test/modules/commit_ts/t/004_restart.pl
index 32be07c..a0a2497 100644
--- a/src/test/modules/commit_ts/t/004_restart.pl
+++ b/src/test/modules/commit_ts/t/004_restart.pl
@@ -54,7 +54,7 @@ my $xid = $node_master->safe_psql(
my $before_restart_ts = $node_master->safe_psql('postgres',
qq[SELECT pg_xact_commit_timestamp('$xid');]);
-ok($before_restart_ts != '' && $before_restart_ts != 'null',
+ok($before_restart_ts ne '' && $before_restart_ts ne 'null',
'commit timestamp recorded');
$node_master->stop('immediate');
* Re: Failure in commit_ts tap tests
@ 2017-01-20 18:10 Tom Lane <tgl@sss.pgh.pa.us>
parent: Pavan Deolasee <pavan.deolasee@gmail.com>
2 siblings, 0 replies; 28+ messages in thread
From: Tom Lane @ 2017-01-20 18:10 UTC (permalink / raw)
To: Pavan Deolasee <pavan.deolasee@gmail.com>; +Cc: pgsql-hackers
Pavan Deolasee <pavan.deolasee@gmail.com> writes:
> I see a consistent failure while running "make -C
> src/test/modules/commit_ts/ check" on a server compiled with
> --enable-tap-tests. This is on the master branch (193a7d791)
> ...
> Changing the operator to "ne" works for me (patch attached). But I wonder
> if this is something specific to my system? Am I using a wrong/stale
> version on OSX Sierra? I'm surprised nobody reported this problem earlier.
That's just weird. I agree this patch is correct (and I see Alvaro
just pushed it), but why isn't the code failing elsewhere? I see
no such warning on my RHEL6 box (perl 5.10.1) nor on my OSX Sierra
laptop (perl 5.18.2, should be same as yours). Do you have any
nondefault Perl modules installed?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-20 18:22 Tom Lane <tgl@sss.pgh.pa.us>
parent: Pavan Deolasee <pavan.deolasee@gmail.com>
2 siblings, 1 reply; 28+ messages in thread
From: Tom Lane @ 2017-01-20 18:22 UTC (permalink / raw)
To: Pavan Deolasee <pavan.deolasee@gmail.com>; +Cc: Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers
Pavan Deolasee <pavan.deolasee@gmail.com> writes:
> I'm surprised nobody reported this problem earlier.
It looks like at least part of the answer is that the buildfarm isn't
running this test. AFAICS, it runs "make installcheck" not
"make check" in src/test/modules. I don't know whether any of the
critters would have duplicated the failure, but they weren't trying.
I don't know if any of the other src/test/modules/ subdirectories
test more in make check mode than make installcheck mode, but if
they do, we probably oughta change the buildfarm script.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-20 18:27 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Pavan Deolasee <pavan.deolasee@gmail.com>
2 siblings, 1 reply; 28+ messages in thread
From: Alvaro Herrera @ 2017-01-20 18:27 UTC (permalink / raw)
To: Pavan Deolasee <pavan.deolasee@gmail.com>; +Cc: pgsql-hackers
Pavan Deolasee wrote:
> Argument "" isn't numeric in numeric ne (!=) at t/004_restart.pl line 57.
> Argument "Fri Jan 20 07:59:52.322811 2017 PST" isn't numeric in numeric ne (!=) at t/004_restart.pl line 57.
> not ok 8 - commit timestamp recorded
>
> Changing the operator to "ne" works for me (patch attached). But I wonder
> if this is something specific to my system? Am I using a wrong/stale
> version on OSX Sierra? I'm surprised nobody reported this problem earlier.
Hmm. The test works fine for me, even if it should be obvious that the
use of the != operator is wrong. I don't understand why it causes a
failure only for you.
> $ perl -v
> This is perl 5, version 18, subversion 2 (v5.18.2) built for
> darwin-thread-multi-2level
> (with 2 registered patches, see perl -V for more detail)
Mine says:
This is perl 5, version 20, subversion 2 (v5.20.2) built for x86_64-linux-gnu-thread-multi
(with 92 registered patches, see perl -V for more detail)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-20 19:15 Tom Lane <tgl@sss.pgh.pa.us>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 1 reply; 28+ messages in thread
From: Tom Lane @ 2017-01-20 19:15 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Hmm. The test works fine for me, even if it should be obvious that the
> use of the != operator is wrong. I don't understand why it causes a
> failure only for you.
Even more interesting, the warning appears as-expected in stripped down
test cases, eg
$ perl -e 'use warnings; use Test::More; ok("Foo" ne "bar", "ok");'
ok 1 - ok
# Tests were run but no plan was declared and done_testing() was not seen.
$ perl -e 'use warnings; use Test::More; ok("Foo" != "bar", "ok");'
Argument "bar" isn't numeric in numeric ne (!=) at -e line 1.
Argument "Foo" isn't numeric in numeric ne (!=) at -e line 1.
not ok 1 - ok
# Failed test 'ok'
# at -e line 1.
# Tests were run but no plan was declared and done_testing() was not seen.
I really don't understand why this complains but the same perl version
is happy with (the previous coding in) 004_restart.pl. Perl bug?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-21 05:40 Pavan Deolasee <pavan.deolasee@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 28+ messages in thread
From: Pavan Deolasee @ 2017-01-21 05:40 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; pgsql-hackers
On Sat, Jan 21, 2017 at 12:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>
> Even more interesting, the warning appears as-expected in stripped down
> test cases, eg
>
> $ perl -e 'use warnings; use Test::More; ok("Foo" ne "bar", "ok");'
> ok 1 - ok
> # Tests were run but no plan was declared and done_testing() was not seen.
>
> $ perl -e 'use warnings; use Test::More; ok("Foo" != "bar", "ok");'
> Argument "bar" isn't numeric in numeric ne (!=) at -e line 1.
> Argument "Foo" isn't numeric in numeric ne (!=) at -e line 1.
> not ok 1 - ok
> # Failed test 'ok'
> # at -e line 1.
> # Tests were run but no plan was declared and done_testing() was not seen.
>
> I really don't understand why this complains but the same perl version
> is happy with (the previous coding in) 004_restart.pl. Perl bug?
>
>
I think I understand why it's only affecting me and not others.
I've PGDATESTYLE set to "Postgres, MDY" in my bashrc and that formats the
commit timestamp as "Fri Jan 20 07:59:52.322811 2017 PST". If I unset that,
the result comes in a format such as "2017-01-20 21:31:47.766371-08".
Looks like perl doesn't throw an error if it can parse the leading part of
the string as a numeric. It still throws a warning, but the test passes.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-21 15:39 Tom Lane <tgl@sss.pgh.pa.us>
parent: Pavan Deolasee <pavan.deolasee@gmail.com>
0 siblings, 1 reply; 28+ messages in thread
From: Tom Lane @ 2017-01-21 15:39 UTC (permalink / raw)
To: Pavan Deolasee <pavan.deolasee@gmail.com>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; pgsql-hackers
Pavan Deolasee <pavan.deolasee@gmail.com> writes:
> I think I understand why it's only affecting me and not others.
> I've PGDATESTYLE set to "Postgres, MDY" in my bashrc and that formats the
> commit timestamp as "Fri Jan 20 07:59:52.322811 2017 PST". If I unset that,
> the result comes in a format such as "2017-01-20 21:31:47.766371-08".
> Looks like perl doesn't throw an error if it can parse the leading part of
> the string as a numeric. It still throws a warning, but the test passes.
Hm, but what of the "null" value? Also, I get
$ perl -e 'use warnings; use Test::More; ok("2017-01-01" != "null", "ok");'
Argument "null" isn't numeric in numeric ne (!=) at -e line 1.
Argument "2017-01-01" isn't numeric in numeric ne (!=) at -e line 1.
ok 1 - ok
# Tests were run but no plan was declared and done_testing() was not seen.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-21 16:02 Pavan Deolasee <pavan.deolasee@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 28+ messages in thread
From: Pavan Deolasee @ 2017-01-21 16:02 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; pgsql-hackers
On Sat, Jan 21, 2017 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>
> Hm, but what of the "null" value? Also, I get
>
> $ perl -e 'use warnings; use Test::More; ok("2017-01-01" != "null", "ok");'
> Argument "null" isn't numeric in numeric ne (!=) at -e line 1.
> Argument "2017-01-01" isn't numeric in numeric ne (!=) at -e line 1.
> ok 1 - ok
>
It declares the test as "passed", right? I am not saying that's a correct
behaviour, but that's why we didn't catch the problem earlier. May be its a
bug in the Test module?
If I add a non-numeric prefix to LHS string, test fails.
$ perl -e 'use warnings; use Test::More; ok("Fri 2017-46" != "null", "ok");'
Argument "null" isn't numeric in numeric ne (!=) at -e line 1.
Argument "Fri 2017-46" isn't numeric in numeric ne (!=) at -e line 1.
not ok 1 - ok
# Failed test 'ok'
# at -e line 1.
# Tests were run but no plan was declared and done_testing() was not seen.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-21 16:09 Tom Lane <tgl@sss.pgh.pa.us>
parent: Pavan Deolasee <pavan.deolasee@gmail.com>
0 siblings, 1 reply; 28+ messages in thread
From: Tom Lane @ 2017-01-21 16:09 UTC (permalink / raw)
To: Pavan Deolasee <pavan.deolasee@gmail.com>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; pgsql-hackers
Pavan Deolasee <pavan.deolasee@gmail.com> writes:
> On Sat, Jan 21, 2017 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hm, but what of the "null" value? Also, I get
>>
>> $ perl -e 'use warnings; use Test::More; ok("2017-01-01" != "null", "ok");'
>> Argument "null" isn't numeric in numeric ne (!=) at -e line 1.
>> Argument "2017-01-01" isn't numeric in numeric ne (!=) at -e line 1.
>> ok 1 - ok
> It declares the test as "passed", right?
Oh! So it does. That is one darn weird behavior of the != operator.
> I am not saying that's a correct
> behaviour, but that's why we didn't catch the problem earlier.
Check. Mystery solved.
There's still the point that we're not actually exercising this script
in the buildfarm ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-21 16:38 Pavan Deolasee <pavan.deolasee@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 28+ messages in thread
From: Pavan Deolasee @ 2017-01-21 16:38 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; pgsql-hackers
On Sat, Jan 21, 2017 at 9:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pavan Deolasee <pavan.deolasee@gmail.com> writes:
> > On Sat, Jan 21, 2017 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Hm, but what of the "null" value? Also, I get
> >>
> >> $ perl -e 'use warnings; use Test::More; ok("2017-01-01" != "null",
> "ok");'
> >> Argument "null" isn't numeric in numeric ne (!=) at -e line 1.
> >> Argument "2017-01-01" isn't numeric in numeric ne (!=) at -e line 1.
> >> ok 1 - ok
>
> > It declares the test as "passed", right?
>
> Oh! So it does. That is one darn weird behavior of the != operator.
>
>
Indeed! See this:
# first numeric matches, doesn't check beyond that
$ perl -e 'if ("2017-23" != "2017-24") {print "Not equal\n"} else {print
"Equal\n"}'
Equal
# first numeric doesn't match, operators works ok
$ perl -e 'if ("2017-23" != "2018-24") {print "Not equal\n"} else {print
"Equal\n"}'
Not equal
# comparison of numeric with non-numeric, works ok
$ perl -e 'if ("2017-23" != "Foo") {print "Not equal\n"} else {print
"Equal\n"}'
Not equal
# numeric on RHS, works ok
$ perl -e 'if ("Foo" != "2018-24") {print "Not equal\n"} else {print
"Equal\n"}'
Not equal
These tests show that the operator returns the correct result it finds a
numeric value at the start of the string, either on LHS or RHS. Also, it
will only compare the numeric values until first non-numeric character is
found.
# no numeric on either side
$ perl -e 'if ("Fri 2017-23" != "Fri 2017-23") {print "Not equal\n"} else
{print "Equal\n"}'
Equal
*# no numeric on either side, arbitrary strings declared as equal*
$ perl -e 'if ("Fri 2017-23" != "Foo") {print "Not equal\n"} else {print
"Equal\n"}'
Equal
These two tests show why we saw no failure earlier. If neither LHS or RHS
string has a starting numeric value, the operator declares the arguments as
equal, irrespective of their values. I tested the same with == operator and
that also exhibits the same behaviour. Weird and I wonder how it's not a
source of constant bugs in perl code (I don't use perl a lot, so may be
those who do are used to either turning warnings on or know this already.
>
>
> There's still the point that we're not actually exercising this script
> in the buildfarm ...
>
Yes indeed.
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-21 20:03 David Bowen <dmb0317@gmail.com>
parent: Pavan Deolasee <pavan.deolasee@gmail.com>
0 siblings, 1 reply; 28+ messages in thread
From: David Bowen @ 2017-01-21 20:03 UTC (permalink / raw)
To: Pavan Deolasee <pavan.deolasee@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Alvaro Herrera <alvherre@2ndquadrant.com>; pgsql-hackers
If the intent of the test is to compare strings, you should be using ne not
!=.
David Bowen
On Sat, Jan 21, 2017 at 10:38 AM, Pavan Deolasee <pavan.deolasee@gmail.com>
wrote:
>
>
> On Sat, Jan 21, 2017 at 9:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> Pavan Deolasee <pavan.deolasee@gmail.com> writes:
>> > On Sat, Jan 21, 2017 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> >> Hm, but what of the "null" value? Also, I get
>> >>
>> >> $ perl -e 'use warnings; use Test::More; ok("2017-01-01" != "null",
>> "ok");'
>> >> Argument "null" isn't numeric in numeric ne (!=) at -e line 1.
>> >> Argument "2017-01-01" isn't numeric in numeric ne (!=) at -e line 1.
>> >> ok 1 - ok
>>
>> > It declares the test as "passed", right?
>>
>> Oh! So it does. That is one darn weird behavior of the != operator.
>>
>>
> Indeed! See this:
>
> # first numeric matches, doesn't check beyond that
> $ perl -e 'if ("2017-23" != "2017-24") {print "Not equal\n"} else {print
> "Equal\n"}'
> Equal
>
> # first numeric doesn't match, operators works ok
> $ perl -e 'if ("2017-23" != "2018-24") {print "Not equal\n"} else {print
> "Equal\n"}'
> Not equal
>
> # comparison of numeric with non-numeric, works ok
> $ perl -e 'if ("2017-23" != "Foo") {print "Not equal\n"} else {print
> "Equal\n"}'
> Not equal
>
> # numeric on RHS, works ok
> $ perl -e 'if ("Foo" != "2018-24") {print "Not equal\n"} else {print
> "Equal\n"}'
> Not equal
>
> These tests show that the operator returns the correct result it finds a
> numeric value at the start of the string, either on LHS or RHS. Also, it
> will only compare the numeric values until first non-numeric character is
> found.
>
> # no numeric on either side
> $ perl -e 'if ("Fri 2017-23" != "Fri 2017-23") {print "Not equal\n"} else
> {print "Equal\n"}'
> Equal
>
> *# no numeric on either side, arbitrary strings declared as equal*
> $ perl -e 'if ("Fri 2017-23" != "Foo") {print "Not equal\n"} else {print
> "Equal\n"}'
> Equal
>
> These two tests show why we saw no failure earlier. If neither LHS or RHS
> string has a starting numeric value, the operator declares the arguments as
> equal, irrespective of their values. I tested the same with == operator and
> that also exhibits the same behaviour. Weird and I wonder how it's not a
> source of constant bugs in perl code (I don't use perl a lot, so may be
> those who do are used to either turning warnings on or know this already.
>
>
>>
>>
>> There's still the point that we're not actually exercising this script
>> in the buildfarm ...
>>
>
> Yes indeed.
>
> Thanks,
> Pavan
>
> --
> Pavan Deolasee http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-21 20:35 Tom Lane <tgl@sss.pgh.pa.us>
parent: David Bowen <dmb0317@gmail.com>
0 siblings, 0 replies; 28+ messages in thread
From: Tom Lane @ 2017-01-21 20:35 UTC (permalink / raw)
To: David Bowen <dmb0317@gmail.com>; +Cc: Pavan Deolasee <pavan.deolasee@gmail.com>; Alvaro Herrera <alvherre@2ndquadrant.com>; pgsql-hackers
David Bowen <dmb0317@gmail.com> writes:
> If the intent of the test is to compare strings, you should be using ne not
> !=.
Sure. We were just confused as to how it had ever appeared to work.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-23 13:28 Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 28+ messages in thread
From: Andrew Dunstan @ 2017-01-23 13:28 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Pavan Deolasee <pavan.deolasee@gmail.com>; +Cc: pgsql-hackers
On 01/20/2017 01:22 PM, Tom Lane wrote:
> Pavan Deolasee <pavan.deolasee@gmail.com> writes:
>> I'm surprised nobody reported this problem earlier.
> It looks like at least part of the answer is that the buildfarm isn't
> running this test. AFAICS, it runs "make installcheck" not
> "make check" in src/test/modules. I don't know whether any of the
> critters would have duplicated the failure, but they weren't trying.
>
> I don't know if any of the other src/test/modules/ subdirectories
> test more in make check mode than make installcheck mode, but if
> they do, we probably oughta change the buildfarm script.
>
>
Is there a reason why these tests aren't run under installcheck? If
there is a justification I can look at it, or we should decide on one
canonical mode of running the tests and stick to that.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-23 14:03 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
0 siblings, 2 replies; 28+ messages in thread
From: Tom Lane @ 2017-01-23 14:03 UTC (permalink / raw)
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; +Cc: Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 01/20/2017 01:22 PM, Tom Lane wrote:
>> It looks like at least part of the answer is that the buildfarm isn't
>> running this test. AFAICS, it runs "make installcheck" not
>> "make check" in src/test/modules. I don't know whether any of the
>> critters would have duplicated the failure, but they weren't trying.
> Is there a reason why these tests aren't run under installcheck? If
> there is a justification I can look at it, or we should decide on one
> canonical mode of running the tests and stick to that.
Well, for at least some of them, "make check" is necessary because they
need to change postmaster parameters or load special shared libraries.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-23 14:20 Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 28+ messages in thread
From: Andrew Dunstan @ 2017-01-23 14:20 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
On 01/23/2017 09:03 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> On 01/20/2017 01:22 PM, Tom Lane wrote:
>>> It looks like at least part of the answer is that the buildfarm isn't
>>> running this test. AFAICS, it runs "make installcheck" not
>>> "make check" in src/test/modules. I don't know whether any of the
>>> critters would have duplicated the failure, but they weren't trying.
>> Is there a reason why these tests aren't run under installcheck? If
>> there is a justification I can look at it, or we should decide on one
>> canonical mode of running the tests and stick to that.
> Well, for at least some of them, "make check" is necessary because they
> need to change postmaster parameters or load special shared libraries.
>
>
OK, so should we just change "make installcheck" to "make check"?
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-23 14:22 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
0 siblings, 1 reply; 28+ messages in thread
From: Tom Lane @ 2017-01-23 14:22 UTC (permalink / raw)
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; +Cc: Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 01/23/2017 09:03 AM, Tom Lane wrote:
>> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>>> On 01/20/2017 01:22 PM, Tom Lane wrote:
>>>> It looks like at least part of the answer is that the buildfarm isn't
>>>> running this test. AFAICS, it runs "make installcheck" not
>>>> "make check" in src/test/modules.
> OK, so should we just change "make installcheck" to "make check"?
I'm in favor (just for src/test/modules, to be clear).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-23 14:23 Stephen Frost <sfrost@snowman.net>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 28+ messages in thread
From: Stephen Frost @ 2017-01-23 14:23 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
Tom, Andrew,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> > On 01/20/2017 01:22 PM, Tom Lane wrote:
> >> It looks like at least part of the answer is that the buildfarm isn't
> >> running this test. AFAICS, it runs "make installcheck" not
> >> "make check" in src/test/modules. I don't know whether any of the
> >> critters would have duplicated the failure, but they weren't trying.
>
> > Is there a reason why these tests aren't run under installcheck? If
> > there is a justification I can look at it, or we should decide on one
> > canonical mode of running the tests and stick to that.
>
> Well, for at least some of them, "make check" is necessary because they
> need to change postmaster parameters or load special shared libraries.
Yes, having to fight with the buildfarm to have something like pgaudit
properly tested by the build animals is extremely frustrating.
The TAP tests do seem to allow that sort of thing these days, though I
haven't peronsally tried to create any which load special shared
libraries yet. I also haven't looked to see how many animals actually
run them, though hopefully we can encourage more people to do so as we
improve our testing with them.
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-24 08:18 Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 28+ messages in thread
From: Andrew Dunstan @ 2017-01-24 08:18 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
On 01/23/2017 09:22 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> On 01/23/2017 09:03 AM, Tom Lane wrote:
>>> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>>>> On 01/20/2017 01:22 PM, Tom Lane wrote:
>>>>> It looks like at least part of the answer is that the buildfarm isn't
>>>>> running this test. AFAICS, it runs "make installcheck" not
>>>>> "make check" in src/test/modules.
>> OK, so should we just change "make installcheck" to "make check"?
> I'm in favor (just for src/test/modules, to be clear).
>
>
Yes. There will be some consequent buildfarm code cleanup, but this will
test shortly on crake.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-24 10:06 Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
parent: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
0 siblings, 1 reply; 28+ messages in thread
From: Andrew Dunstan @ 2017-01-24 10:06 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
On 01/24/2017 03:18 AM, Andrew Dunstan wrote:
>
> On 01/23/2017 09:22 AM, Tom Lane wrote:
>> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>>> On 01/23/2017 09:03 AM, Tom Lane wrote:
>>>> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>>>>> On 01/20/2017 01:22 PM, Tom Lane wrote:
>>>>>> It looks like at least part of the answer is that the buildfarm isn't
>>>>>> running this test. AFAICS, it runs "make installcheck" not
>>>>>> "make check" in src/test/modules.
>>> OK, so should we just change "make installcheck" to "make check"?
>> I'm in favor (just for src/test/modules, to be clear).
>>
>>
>
>
> Yes. There will be some consequent buildfarm code cleanup, but this will
> test shortly on crake.
>
Well, that crashed. The DDL deparse comment test should not assume that
contrib_regression exists. Possibly it should create it if it doesn't
exist. The buildfarm mostly runs with USE_DB_MODULE=1 so we don't
constantly overwrite the same db.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-24 10:17 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
0 siblings, 1 reply; 28+ messages in thread
From: Alvaro Herrera @ 2017-01-24 10:17 UTC (permalink / raw)
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
Andrew Dunstan wrote:
> Well, that crashed. The DDL deparse comment test should not assume that
> contrib_regression exists. Possibly it should create it if it doesn't
> exist. The buildfarm mostly runs with USE_DB_MODULE=1 so we don't
> constantly overwrite the same db.
Maybe we can drop that line and put it back once we get COMMENT ON
CURRENT_DATABASE.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-24 11:36 Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 1 reply; 28+ messages in thread
From: Andrew Dunstan @ 2017-01-24 11:36 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
On 01/24/2017 05:17 AM, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
>> Well, that crashed. The DDL deparse comment test should not assume that
>> contrib_regression exists. Possibly it should create it if it doesn't
>> exist. The buildfarm mostly runs with USE_DB_MODULE=1 so we don't
>> constantly overwrite the same db.
> Maybe we can drop that line and put it back once we get COMMENT ON
> CURRENT_DATABASE.
>
Works for me.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-24 13:12 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
0 siblings, 1 reply; 28+ messages in thread
From: Tom Lane @ 2017-01-24 13:12 UTC (permalink / raw)
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 01/24/2017 05:17 AM, Alvaro Herrera wrote:
>> Maybe we can drop that line and put it back once we get COMMENT ON
>> CURRENT_DATABASE.
> Works for me.
If that's enough to get the "make check" cases passing in the buildfarm,
then +1.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-26 20:50 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 28+ messages in thread
From: Alvaro Herrera @ 2017-01-26 20:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> > On 01/24/2017 05:17 AM, Alvaro Herrera wrote:
> >> Maybe we can drop that line and put it back once we get COMMENT ON
> >> CURRENT_DATABASE.
>
> > Works for me.
>
> If that's enough to get the "make check" cases passing in the buildfarm,
> then +1.
Okay, done.
It is really quite annoying that the buildfarm doesn't do what stock
tests do. What about pushing a bit stronger for having these
optimizations as part of the standard build run, instead of being only
in the buildfarm client script?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-26 21:16 Tom Lane <tgl@sss.pgh.pa.us>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
1 sibling, 1 reply; 28+ messages in thread
From: Tom Lane @ 2017-01-26 21:16 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> It is really quite annoying that the buildfarm doesn't do what stock
> tests do. What about pushing a bit stronger for having these
> optimizations as part of the standard build run, instead of being only
> in the buildfarm client script?
Huh? It's just a question of "make check" vs "make installcheck".
They each have their uses.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-26 21:46 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 28+ messages in thread
From: Alvaro Herrera @ 2017-01-26 21:46 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > It is really quite annoying that the buildfarm doesn't do what stock
> > tests do. What about pushing a bit stronger for having these
> > optimizations as part of the standard build run, instead of being only
> > in the buildfarm client script?
>
> Huh? It's just a question of "make check" vs "make installcheck".
> They each have their uses.
The current problem is because the buildfarm uses a different database.
See https://postgr.es/m/e6084b89-07a7-7e57-51ee-d7b8fc9ec864@2ndQuadrant.com
(When I wrote the para quoted above, I thought this was for performance,
but now I realize it's not so. Anyway the point stands that buildfarm
does things differently.)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-27 08:35 Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
1 sibling, 1 reply; 28+ messages in thread
From: Andrew Dunstan @ 2017-01-27 08:35 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
On 01/26/2017 03:50 PM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>>> On 01/24/2017 05:17 AM, Alvaro Herrera wrote:
>>>> Maybe we can drop that line and put it back once we get COMMENT ON
>>>> CURRENT_DATABASE.
>>> Works for me.
>> If that's enough to get the "make check" cases passing in the buildfarm,
>> then +1.
> Okay, done.
>
> It is really quite annoying that the buildfarm doesn't do what stock
> tests do. What about pushing a bit stronger for having these
> optimizations as part of the standard build run, instead of being only
> in the buildfarm client script?
>
There is nothing that the buildfarm does that's not a stock test. What
it does is run the stock tests with USE_MODULE_DB=1 (which you can do
too). That is something provided for in our Make files. The reason is
that otherwise we constantly overwrite the regression database. That can
make it a lot harder to go back after a buildfarm run and find errors.
That's why you should not assume the name of the database when you're
writing a test.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-27 12:22 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
0 siblings, 1 reply; 28+ messages in thread
From: Alvaro Herrera @ 2017-01-27 12:22 UTC (permalink / raw)
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
Andrew Dunstan wrote:
> On 01/26/2017 03:50 PM, Alvaro Herrera wrote:
> > It is really quite annoying that the buildfarm doesn't do what stock
> > tests do. What about pushing a bit stronger for having these
> > optimizations as part of the standard build run, instead of being only
> > in the buildfarm client script?
>
> There is nothing that the buildfarm does that's not a stock test. What
> it does is run the stock tests with USE_MODULE_DB=1 (which you can do
> too). That is something provided for in our Make files. The reason is
> that otherwise we constantly overwrite the regression database. That can
> make it a lot harder to go back after a buildfarm run and find errors.
There is a lot that you *can* do using the stock makefiles, but that
"make check-world" doesn't do. Why aren't we using USE_MODULE_DB=1 in
"make check-world", is my question.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: Failure in commit_ts tap tests
@ 2017-01-27 12:56 Tom Lane <tgl@sss.pgh.pa.us>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 0 replies; 28+ messages in thread
From: Tom Lane @ 2017-01-27 12:56 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Pavan Deolasee <pavan.deolasee@gmail.com>; pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> There is a lot that you *can* do using the stock makefiles, but that
> "make check-world" doesn't do. Why aren't we using USE_MODULE_DB=1 in
> "make check-world", is my question.
Well, that option isn't all that convenient for manual use ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 28+ messages in thread
end of thread, other threads:[~2017-01-27 12:56 UTC | newest]
Thread overview: 28+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2017-01-20 17:23 Failure in commit_ts tap tests Pavan Deolasee <pavan.deolasee@gmail.com>
2017-01-20 18:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-01-20 18:22 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-01-23 13:28 ` Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2017-01-23 14:03 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-01-23 14:20 ` Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2017-01-23 14:22 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-01-24 08:18 ` Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2017-01-24 10:06 ` Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2017-01-24 10:17 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2017-01-24 11:36 ` Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2017-01-24 13:12 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-01-26 20:50 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2017-01-26 21:16 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-01-26 21:46 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2017-01-27 08:35 ` Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2017-01-27 12:22 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2017-01-27 12:56 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-01-23 14:23 ` Stephen Frost <sfrost@snowman.net>
2017-01-20 18:27 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2017-01-20 19:15 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-01-21 05:40 ` Pavan Deolasee <pavan.deolasee@gmail.com>
2017-01-21 15:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-01-21 16:02 ` Pavan Deolasee <pavan.deolasee@gmail.com>
2017-01-21 16:09 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-01-21 16:38 ` Pavan Deolasee <pavan.deolasee@gmail.com>
2017-01-21 20:03 ` David Bowen <dmb0317@gmail.com>
2017-01-21 20:35 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox