(Moviendo mi respuesta de Uso de PostgreSQL en memoria y generalizándola):
No puede ejecutar Pg en proceso, en memoria
No puedo averiguar cómo ejecutar la base de datos Postgres en memoria para realizar pruebas. ¿Es posible?
No, no es posible. PostgreSQL se implementa en C y se compila en el código de la plataforma. A diferencia de H2 o Derby, no puede simplemente cargar el jar y enciéndalo como una base de datos desechable en memoria.
A diferencia de SQLite, que también está escrito en C y compilado en el código de la plataforma, PostgreSQL tampoco se puede cargar en el proceso. Requiere múltiples procesos (uno por conexión) porque es una arquitectura de multiprocesamiento, no de subprocesos múltiples. El requisito de multiprocesamiento significa que debe inicie el postmaster como un proceso independiente.
En su lugar:preconfigurar una conexión
Sugiero simplemente escribir sus pruebas para esperar que funcione un nombre de host/nombre de usuario/contraseña en particular, y hacer que la prueba aproveche CREATE DATABASE una base de datos descartable, luego DROP DATABASE al final de la carrera. Obtenga los detalles de conexión de la base de datos de un archivo de propiedades, cree propiedades de destino, variable de entorno, etc.
Es seguro usar una instancia de PostgreSQL existente en la que ya tiene bases de datos que le interesan, siempre que el usuario que proporcione a sus pruebas unitarias no un superusuario, solo un usuario con CREATEDB derechos. En el peor de los casos, creará problemas de rendimiento en las otras bases de datos. Prefiero ejecutar una instalación de PostgreSQL completamente aislada para realizar pruebas por ese motivo.
En su lugar:inicie una instancia de PostgreSQL descartable para realizar pruebas
Alternativamente, si estás realmente desea que su arnés de prueba localice el initdb y postgres binarios, ejecute initdb para crear una base de datos, modifique pg_hba.conf trust , ejecuta postgres para iniciarlo en un puerto aleatorio, cree un usuario, cree una base de datos y ejecute las pruebas. Incluso podría agrupar los archivos binarios de PostgreSQL para varias arquitecturas en un contenedor y descomprimir los de la arquitectura actual en un directorio temporal antes de ejecutar las pruebas.
Personalmente, creo que es un gran dolor que debe evitarse; es mucho más fácil tener una base de datos de prueba configurada. Sin embargo, se ha vuelto un poco más fácil con la llegada de include_dir soporte en postgresql.conf; ahora solo puede agregar una línea y luego escribir un archivo de configuración generado para el resto.
Pruebas más rápidas con PostgreSQL
Para obtener más información sobre cómo de forma segura mejorar el rendimiento de PostgreSQL con fines de prueba, vea una respuesta detallada que escribí sobre este tema anteriormente:Optimizar PostgreSQL para pruebas rápidas
El dialecto PostgreSQL de H2 no es un verdadero sustituto
En cambio, algunas personas usan la base de datos H2 en el modo de dialecto de PostgreSQL para ejecutar pruebas. Creo que eso es casi tan malo como que la gente de Rails use SQLite para pruebas y PostgreSQL para implementación en producción.
H2 admite algunas extensiones de PostgreSQL y emula el dialecto de PostgreSQL. Sin embargo, es solo eso:una emulación. Encontrará áreas donde H2 acepta una consulta pero PostgreSQL no, donde el comportamiento difiere, etc. También encontrará muchos lugares donde PostgreSQL admite hacer algo que H2 simplemente no puede, como funciones de ventana, en el momento de escribiendo.
Si comprende las limitaciones de este enfoque y su acceso a la base de datos es simple, H2 podría estar bien. Pero en ese caso, probablemente sea un mejor candidato para un ORM que abstraiga la base de datos porque de todos modos no está utilizando sus características interesantes, y en ese caso, ya no tiene que preocuparse tanto por la compatibilidad de la base de datos.
¡Los tablespaces no son la respuesta!
no use un tablespace para crear una base de datos "en memoria". No solo es innecesario, ya que no ayudará significativamente al rendimiento de todos modos, sino que también es una excelente manera de interrumpir el acceso a cualquier otro que le interese en la misma instalación de PostgreSQL. La documentación de 9.4 ahora contiene la siguiente advertencia:
ADVERTENCIA
Aunque se encuentran fuera del directorio de datos principal de PostgreSQL, los espacios de tablas son una parte integral del clúster de la base de datos y no pueden tratarse como una colección autónoma de archivos de datos. Dependen de los metadatos contenidos en el directorio de datos principal y, por lo tanto, no se pueden adjuntar a un clúster de base de datos diferente ni hacer una copia de seguridad de forma individual. para comenzar. Colocar un tablespace en un sistema de archivos temporal como un ramdisk pone en riesgo la confiabilidad de todo el clúster.
porque me di cuenta de que demasiadas personas estaban haciendo esto y se estaban metiendo en problemas.
(Si ha hecho esto, puede mkdir el directorio del tablespace faltante para que PostgreSQL comience de nuevo, luego DROP las bases de datos, tablas, etc. que faltan. Es mejor simplemente no hacerlo).
