Re: Conflict between regression tests namespace & transactions due to recent changes
Вложения
В списке pgsql-hackers по дате отправления:
| От | Marina Polyakova |
|---|---|
| Тема | Re: Conflict between regression tests namespace & transactions due to recent changes |
| Дата | |
| Msg-id | f62cd65e1b179783521f424a42ef3b27@postgrespro.ru обсуждение исходный текст |
| Ответ на | Re: Conflict between regression tests namespace & transactions due to recent changes (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Conflict between regression tests namespace & transactions due to recent changes
|
| Список | pgsql-hackers |
On 2023-05-15 19:16, Tom Lane wrote: > Marina Polyakova <m.polyakova@postgrespro.ru> writes: >> IIUC the conflict was caused by > >> +SET search_path to public, test_ns_schema_1; >> +CREATE SCHEMA test_ns_schema_2 >> + CREATE VIEW abc_view AS SELECT a FROM abc; > >> because the parallel regression test transactions had already created >> the table abc and was trying to drop it. > > Hmm. I'd actually fix the blame on transactions.sql here. Creating > a table named as generically as "abc" is horribly bad practice in > a set of concurrent tests. namespace.sql is arguably okay, since > it's creating that table name in a private schema. > > I'd be inclined to fix this by doing s/abc/something-else/g in > transactions.sql. > > regards, tom lane Maybe use a separate schema for all new objects in the transaction test?.. See diff_set_tx_schema.patch. -- Marina Polyakova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера