pgsql: Don't run rowsecurity in parallel with other regression tests.
Don't run rowsecurity in parallel with other regression tests.
The short-lived event trigger in the rowsecurity test causes irreproducible
failures when the concurrent tests do something that the event trigger
can't cope with. Per buildfarm.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/7161b082bd9fc51e67a1031ea9d0313e8a48286b
Modified Files
--------------
src/test/regress/parallel_schedule | 7 +++++--
src/test/regress/serial_schedule | 2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Tom Lane wrote:
Don't run rowsecurity in parallel with other regression tests.
The short-lived event trigger in the rowsecurity test causes irreproducible
failures when the concurrent tests do something that the event trigger
can't cope with. Per buildfarm.
Ah, so this explains the failures.
I wonder if it'd be better to remove the event trigger bits from that
test, and put them (if we really need them) in the event_trigger test.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Tom Lane wrote:
Don't run rowsecurity in parallel with other regression tests.
The short-lived event trigger in the rowsecurity test causes irreproducible
failures when the concurrent tests do something that the event trigger
can't cope with. Per buildfarm.
Ah, so this explains the failures.
I wonder if it'd be better to remove the event trigger bits from that
test, and put them (if we really need them) in the event_trigger test.
I'd be fine with reverting this commit if Stephen wants to refactor the
rowsecurity/event_trigger tests that way. Dunno if it makes sense to
do that though.
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Tom Lane wrote:
Don't run rowsecurity in parallel with other regression tests.
The short-lived event trigger in the rowsecurity test causes irreproducible
failures when the concurrent tests do something that the event trigger
can't cope with. Per buildfarm.Ah, so this explains the failures.
I wonder if it'd be better to remove the event trigger bits from that
test, and put them (if we really need them) in the event_trigger test.
That makes sense to me.
I'd be fine with reverting this commit if Stephen wants to refactor the
rowsecurity/event_trigger tests that way. Dunno if it makes sense to
do that though.
I'll move the event trigger in the rowsecurity tests over to the
event_trigger test and then move the rowsecurity tests back into the
parallel group.
Please let me know if there's any concerns with this approach.
Thanks!
Stephen
Stephen Frost wrote:
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
I'd be fine with reverting this commit if Stephen wants to refactor the
rowsecurity/event_trigger tests that way. Dunno if it makes sense to
do that though.I'll move the event trigger in the rowsecurity tests over to the
event_trigger test and then move the rowsecurity tests back into the
parallel group.Please let me know if there's any concerns with this approach.
Sounds good to me, thanks.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers