Обсуждение: pgsql: Fix timing issue in new subscription truncate test
Fix timing issue in new subscription truncate test We need to wait for the initial sync of all subscriptions. On some (faster?) machines, this didn't make a difference, but the (slower?) buildfarm machines are upset. Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/529ab7bd1fb9c836fe5ccd96f79329d407522e20 Modified Files -------------- src/test/subscription/t/010_truncate.pl | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
On April 7, 2018 9:59:34 AM PDT, Peter Eisentraut <peter_e@gmx.net> wrote: >Fix timing issue in new subscription truncate test > >We need to wait for the initial sync of all subscriptions. On >some (faster?) machines, this didn't make a difference, but >the (slower?) buildfarm machines are upset. Failed on my very fast laptop fwiw. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Andres Freund <andres@anarazel.de> writes:
> On April 7, 2018 9:59:34 AM PDT, Peter Eisentraut <peter_e@gmx.net> wrote:
>> We need to wait for the initial sync of all subscriptions. On
>> some (faster?) machines, this didn't make a difference, but
>> the (slower?) buildfarm machines are upset.
> Failed on my very fast laptop fwiw.
I'm a bit suspicious of that analysis too, as it was the faster buildfarm
machines that were reporting the first wave of failures. (A lot of the
slow ones aren't configured to run subscription-check at all, I think.)
Testing the fix here, I just noticed that there's a pre-existing
problem in subscription/t/002_types.pl. It passes make check OK,
but make installcheck not so much. Investigating ...
regards, tom lane
I wrote:
> Testing the fix here, I just noticed that there's a pre-existing
> problem in subscription/t/002_types.pl. It passes make check OK,
> but make installcheck not so much. Investigating ...
Oh ... digging into that, it's because that test depends on hstore,
which I hadn't installed. How much is that dependency really
buying us? If there's a good reason to have it, we should
(a) document the requirement in src/test/subscription/README,
and (b) try to make the failure less obscure. I do not really find
this to be an acceptable spelling of "you didn't install hstore":
t/001_rep_changes.pl .. ok
t/002_types.pl ........ # Looks like your test exited with 29 before it could output anything.
t/002_types.pl ........ Dubious, test returned 29 (wstat 7424, 0x1d00)
Failed 3/3 subtests
t/003_constraints.pl .. ok
t/004_sync.pl ......... ok
t/005_encoding.pl ..... ok
t/006_rewrite.pl ...... ok
t/007_ddl.pl .......... ok
t/008_diff_schema.pl .. ok
t/009_matviews.pl ..... ok
t/010_truncate.pl ..... ok
Test Summary Report
-------------------
t/002_types.pl (Wstat: 7424 Tests: 0 Failed: 0)
Non-zero exit status: 29
Parse errors: Bad plan. You planned 3 tests but ran 0.
Files=10, Tests=45, 56 wallclock secs ( 0.07 usr 0.03 sys + 32.69 cusr 10.18 csys = 42.97 CPU)
Result: FAIL
regards, tom lane
Hi, On 2018-04-07 13:31:53 -0400, Tom Lane wrote: > Oh ... digging into that, it's because that test depends on hstore, > which I hadn't installed. How much is that dependency really > buying us? There's some separate logic for non-core datatypes, so it seems good to test that. Hstore seems like a reasonable choice for it. > If there's a good reason to have it, we should > (a) document the requirement in src/test/subscription/README, > and (b) try to make the failure less obscure. I do not really find > this to be an acceptable spelling of "you didn't install hstore": No argument there. Greetings, Andres Freund