Thread: rules regression test fix
I've been seeing some intermittent failures in the 'rules' regression tests. I believe this patch should fix that, by moving rules out of the parallel group it is currently in. Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Attachment
Neil Conway <neilc@samurai.com> writes:
> I've been seeing some intermittent failures in the 'rules' regression
> tests. I believe this patch should fix that, by moving rules out of
> the parallel group it is currently in.
What intermittent failure? The only failure I'm currently aware of
is the hard failure from not having updated the expected output for
your pg_locks change.
I'm not eager to reduce the parallelism of the tests without hard
evidence that it's necessary ...
regards, tom lane
Tom Lane wrote: > Neil Conway <neilc@samurai.com> writes: > > I've been seeing some intermittent failures in the 'rules' regression > > tests. I believe this patch should fix that, by moving rules out of > > the parallel group it is currently in. > > What intermittent failure? The only failure I'm currently aware of > is the hard failure from not having updated the expected output for > your pg_locks change. Already done. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Neil Conway <neilc@samurai.com> writes:
> I've been seeing some intermittent failures in the 'rules' regression
> tests. I believe this patch should fix that, by moving rules out of
> the parallel group it is currently in.
>>
>> What intermittent failure? The only failure I'm currently aware of
>> is the hard failure from not having updated the expected output for
>> your pg_locks change.
> Already done.
Yes, I saw your commit, but haven't done cvs update since about noon.
This brings up something I'd had as a mental TODO for awhile: how can we
verify that the parallel regression test sets are actually safe
(noninterfering)? One fairly simple check would be a brute-force one:
for each test in a parallel set, try it before and after the set.
For example, with a set
test: a b c
try all the cases
test: a
test: b c
test: b c
test: a
test: b
test: a c
test: a c
test: b
test: c
test: a b
test: a b
test: c
to see if any fail. This would catch any places where there are
unexpected sequential dependencies between tests.
This would *not* catch problems created by transient states within a
test. For example, if some test running parallel with the rules test
were to create a temp table and put a rule on the temp table, then the
rules test's display of all rules might show that rule when run in
parallel ... but there's no bug in either sequential order.
I think it'd be worth trying the cross-check sketched above, if anyone
has the patience, but beyond that I'm not sure how we might rule out
problems.
But in reality, if there were such problems I'd be inclined to think
we'd have heard about them before now.
regards, tom lane
Tom Lane wrote: > I think it'd be worth trying the cross-check sketched above, if anyone > has the patience, but beyond that I'm not sure how we might rule out > problems. > > But in reality, if there were such problems I'd be inclined to think > we'd have heard about them before now. Yes, in a way we hear about parallel problem from failure reports. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Tom Lane wrote: > This would *not* catch problems created by transient states within a > test. For example, if some test running parallel with the rules test > were to create a temp table and put a rule on the temp table, then the > rules test's display of all rules might show that rule when run in > parallel ... but there's no bug in either sequential order. > > I think it'd be worth trying the cross-check sketched above, if anyone > has the patience, but beyond that I'm not sure how we might rule out > problems. > > But in reality, if there were such problems I'd be inclined to think > we'd have heard about them before now. > I've seen this kind of problem before, but not often enough to bother me. I was actually thinking that each parallel test should use its own schema. Joe
Joe Conway <mail@joeconway.com> writes:
> I've seen this kind of problem before, but not often enough to bother
> me. I was actually thinking that each parallel test should use its own
> schema.
That's a thought, but again it's only a partial solution. Stuff that
looks directly at the system catalogs (like the rules regression test)
isn't going to be magically insulated by having a separate schema...
regards, tom lane
Neil Conway <neilc@samurai.com> writes: > I've been seeing some intermittent failures in the 'rules' regression > tests. (Tom asked what the root cause of the failure was, but I lost that email, sorry) It took me a while for the problem to occur again. I've attached the regression.diffs file that was produced -- any ideas what the problem is? Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Attachment
Neil Conway <neilc@samurai.com> writes:
> It took me a while for the problem to occur again. I've attached the
> regression.diffs file that was produced -- any ideas what the problem
> is?
> SELECT tablename, rulename, definition FROM pg_rules
> ORDER BY tablename, rulename;
> ! ERROR: cache lookup of relation 144145 failed
At a guess, something is dropping a table that had a rule just as the
rules test tries to print out the rule definition.
Do we have any concurrent tests that create/drop views, or tables with
rules on them?
regards, tom lane
Tom Lane dijo: > Neil Conway <neilc@samurai.com> writes: > > It took me a while for the problem to occur again. I've attached the > > regression.diffs file that was produced -- any ideas what the problem > > is? > > > SELECT tablename, rulename, definition FROM pg_rules > > ORDER BY tablename, rulename; > > ! ERROR: cache lookup of relation 144145 failed > > At a guess, something is dropping a table that had a rule just as the > rules test tries to print out the rule definition. > > Do we have any concurrent tests that create/drop views, or tables with > rules on them? Yes, alter_table. -- Alvaro Herrera (<alvherre[a]atentus.com>) "El Maquinismo fue proscrito so pena de cosquilleo hasta la muerte" (Ijon Tichy en Viajes, Stanislaw Lem)
Alvaro Herrera <alvherre@atentus.com> writes: > Tom Lane dijo: > > Do we have any concurrent tests that create/drop views, or tables with > > rules on them? > > Yes, alter_table. Okay, attached is a patch that moves the alter table regression test into a separate parallel group. I can't confirm that this fixes the problem for me (since it only occurs about one in ten or one in twenty runs), but I think it's a good bet that it does... Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Attachment
Your patch has been added to the PostgreSQL unapplied patches list at:
http://207.106.42.251/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Neil Conway wrote:
> Alvaro Herrera <alvherre@atentus.com> writes:
> > Tom Lane dijo:
> > > Do we have any concurrent tests that create/drop views, or tables with
> > > rules on them?
> >
> > Yes, alter_table.
>
> Okay, attached is a patch that moves the alter table regression test
> into a separate parallel group. I can't confirm that this fixes the
> problem for me (since it only occurs about one in ten or one in twenty
> runs), but I think it's a good bet that it does...
>
> Cheers,
>
> Neil
>
> --
> Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Patch applied. Thanks. --------------------------------------------------------------------------- Neil Conway wrote: > Alvaro Herrera <alvherre@atentus.com> writes: > > Tom Lane dijo: > > > Do we have any concurrent tests that create/drop views, or tables with > > > rules on them? > > > > Yes, alter_table. > > Okay, attached is a patch that moves the alter table regression test > into a separate parallel group. I can't confirm that this fixes the > problem for me (since it only occurs about one in ten or one in twenty > runs), but I think it's a good bet that it does... > > Cheers, > > Neil > > -- > Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073