(Премествам отговора си от Използване на PostgreSQL в паметта и го обобщавам):
Не можете да стартирате Pg в процес, в паметта
Не мога да разбера как да стартирам Postgres база данни в паметта за тестване. Възможно ли е?
Не, не е възможно. PostgreSQL е внедрен на C и компилиран в код на платформата. За разлика от H2 или Derby не можете просто да заредите jar и го задействайте като изхвърляна БД в паметта.
За разлика от SQLite, който също е написан на C и компилиран в код на платформата, PostgreSQL също не може да бъде зареден в процес. Изисква множество процеси (по един на връзка), защото е многопроцесорна, а не многонишкова архитектура. Изискването за многопроцесорност означава, че трябва стартирайте пощенския администратор като самостоятелен процес.
Вместо това:предварително конфигурирайте връзка
Предлагам просто да напишете вашите тестове, за да очаквате конкретно име на хост/потребителско име/парола да работят, и да имате тестовия сноп CREATE DATABASE база данни за изхвърляне, след това DROP DATABASE в края на бягането. Вземете подробности за връзката към базата данни от файл със свойства, изградете целеви свойства, променлива на средата и т.н.
Безопасно е да използвате съществуващ екземпляр на PostgreSQL, в който вече имате бази данни, които ви интересуват, стига потребителят, който предоставяте на вашите модулни тестове, не суперпотребител, само потребител с CREATEDB права. В най-лошия случай ще създадете проблеми с производителността в другите бази данни. Поради тази причина предпочитам да стартирам напълно изолирана инсталация на PostgreSQL за тестване.
Вместо това:Стартирайте изхвърлян екземпляр на PostgreSQL за тестване
Алтернативно, ако сте наистина желаете да накарате тестовия ви колан да намери initdb и postgres двоични файлове, стартирайте initdb за да създадете база данни, променете pg_hba.conf на trust , стартирайте postgres за да го стартирате на произволен порт, създайте потребител, създайте DB и стартирайте тестовете. Можете дори да групирате двоичните файлове на PostgreSQL за множество архитектури в буркан и да разопаковате тези за текущата архитектура във временна директория, преди да стартирате тестовете.
Лично аз смятам, че това е голяма болка, която трябва да се избягва; много по-лесно е просто да конфигурирате тестова БД. Въпреки това, стана малко по-лесно с появата на include_dir поддръжка в postgresql.conf; сега можете просто да добавите един ред, след което да напишете генериран конфигурационен файл за всички останали.
По-бързо тестване с PostgreSQL
За повече информация как да безопасно подобрете производителността на PostgreSQL за целите на тестването, вижте подробния отговор, който написах по тази тема по-рано:Оптимизирайте PostgreSQL за бързо тестване
Диалектът на H2 на PostgreSQL не е истински заместител
Някои хора вместо това използват базата данни H2 в диалектен режим на PostgreSQL, за да стартират тестове. Мисля, че това е почти толкова лошо, колкото хората от Rails, които използват SQLite за тестване и PostgreSQL за производствено внедряване.
H2 поддържа някои разширения на PostgreSQL и емулира диалекта на PostgreSQL. Обаче това е просто - емулация. Ще намерите области, в които H2 приема заявка, но PostgreSQL не, където поведението се различава и т.н. Ще намерите и много места, където PostgreSQL поддържа да прави нещо, което H2 просто не може - като функции на прозореца, в момента на писане.
Ако разбирате ограниченията на този подход и достъпът до вашата база данни е прост, H2 може да е наред. Но в този случай вероятно сте по-добър кандидат за ORM, който абстрахира базата данни, защото така или иначе не използвате нейните интересни функции – и в този случай вече не е нужно да се интересувате толкова от съвместимостта на базата данни.
Пространствата за таблици не са отговорът!
Не използвайте пространство за таблици, за да създадете база данни "в паметта". Не само, че е ненужно, тъй като така или иначе няма да помогне значително на производителността, но също така е чудесен начин да нарушите достъпа до всеки друг, който може да ви интересува в същата инсталация на PostgreSQL. Документацията 9.4 вече съдържа следното предупреждение:
ПРЕДУПРЕЖДЕНИЕ
Въпреки че са разположени извън основната директория с данни на PostgreSQL, пространствата за таблици са неразделна част от клъстера на базата данни и не могат да се третират като автономна колекция от файлове с данни. Те зависят от метаданните, съдържащи се в главната директория с данни и следователно не могат да бъдат прикачени към друг клъстер на база данни или архивирани поотделно. По същия начин, ако загубите пространство за таблици (изтриване на файл, повреда на диска и т.н.), клъстерът на базата данни може да стане нечетим или неспособен за да започнете. Поставянето на пространство за таблици във временна файлова система като ramdisk рискува надеждността на целия клъстер.
защото забелязах, че твърде много хора правят това и се сблъскват с проблеми.
(Ако сте направили това, можете да mkdir липсващата директория на пространството за таблици, за да накара PostgreSQL да стартира отново, след което DROP липсващите бази данни, таблици и т.н. По-добре е просто да не го правите.)
