Обсуждение: 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(-)
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
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
* 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