Re: pgsql: Don't run rowsecurity in parallel with other regression tests.
Вложения
В списке pgsql-committers по дате отправления:
| От | Stephen Frost |
|---|---|
| Тема | Re: pgsql: Don't run rowsecurity in parallel with other regression tests. |
| Дата | |
| Msg-id | 20150102134729.GY3062@tamriel.snowman.net обсуждение исходный текст |
| Ответ на | Re: pgsql: Don't run rowsecurity in parallel with other regression tests. (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: pgsql: Don't run rowsecurity in parallel with other
regression tests.
|
| Список | 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
В списке pgsql-committers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера