| 1 |
On Mon, 12 May 2014 19:39:09 +0200 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> I don't know postgresql well enough but does the test db reside |
| 5 |
> in temporary build directory? That is, can you guarantee that: |
| 6 |
> |
| 7 |
> 1) it will never ever collide with user's database, |
| 8 |
> |
| 9 |
> 2) it will be properly cleaned up even if the test suite terminates |
| 10 |
> unexpectedly? |
| 11 |
|
| 12 |
The closest thing you could do would be to create a separate tablespace |
| 13 |
residing in the build directory. I wouldn't consider this a good idea |
| 14 |
however, as you'd need postgres superuser permissions, it would have |
| 15 |
some unintented side effects (like breaking on SELinux machines), you'd |
| 16 |
have to patch the test suites and it still wouldn't ensure an automatic |
| 17 |
cleanup -- on unexpected test suite terminations the dir in which the |
| 18 |
tablespace resides would vanish, but postgres would still expect one |
| 19 |
there, which might even create further problems (especially on |
| 20 |
re-emerge). I wouldn't recommend using this approach even when |
| 21 |
accessing the host postgres. |
| 22 |
|
| 23 |
On top of that, many postgres installations with reasonably secure |
| 24 |
configuration wouldn't grant portage access anyway. |
| 25 |
|
| 26 |
As it isn't hard at all to run a separate postgres instance (upstream |
| 27 |
is explicitly supporting it), I'd strongly recommend doing so even with |
| 28 |
network-sandbox being disabled. |
| 29 |
|
| 30 |
|
| 31 |
-- |
| 32 |
Regards, |
| 33 |
Luis Ressel |
Archives