rules regression test fix

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

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

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