Filled Postgres server as Docker image
Hi, for development and testing (integration testing) I want to have a Docker image with a pre-filled Postgres database. It should be a simple and quick task to spin-up this database, e.g., in a docker compose setup. Suggested solutions to achieve this goal are (1) To place initialization scripts at /docker-entrypoint-initdb.d and do the filling of the DB when the container is started the first time -> I want to avoid this, as it takes 20 minutes (2) To mount a volume to /var/lib/postgresql and have the data there -> I want to avoid this, as it requires to move and maintain the data folder separately Not suggested (at least this is what I found at mailing lists and at StackOverflow) is to burn the data into the container image. However, the reasons that are mentioned in these discussions "data is gone when the container is gone ..." is not my concern. As it is not easy to write a Docker build to achieve my goal, I would like to ask if there are reference projects / Docker build processes that perform this workflow? Reason why I consider it as not too easy: I have to manually start the Postgres server ignoring the intended entry-point script and then fill it with my data. Looking forward to your comments/suggestions! Bernd
Re: Filled Postgres server as Docker image
El día viernes, enero 05, 2024 a las 11:31:34 +0100, Bernd Graf escribió: > Hi, > > for development and testing (integration testing) I want to have a > Docker image with a pre-filled Postgres database. It should be a simple > and quick task to spin-up this database, e.g., in a docker compose setup. > > Suggested solutions to achieve this goal are > > (1) To place initialization scripts at /docker-entrypoint-initdb.d and > do the filling of the DB when the container is started the first time -> > I want to avoid this, as it takes 20 minutes > > ... Interesting, I'm working on a similar project. Having a podman image, with: - SuSE SLES 15 - PostgreSQL 15.x server with loaded database - starting a bunch of application server on top of the PostgreSQL server and offering there service on network sockets; - and (ofc) having SSH into the image for debugging/testing; I plan to have a similar PostgreSQL server outside the image, with loaded database. Shut this down and create a tar archive of the full server which then will be COPY'ed into the image at build time and scripts in /entrypoint.d will arange everything. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.
Hard max_stack_depth / WIN32_STACK_RLIMIT PostgreSQL Windows Query
Hi all, I am on a bit of fact-finding mission for a problem we are hitting with PostgreSQL on Windows. I am unable to start PostgreSQL on windows if I have the max_stack_depth limit greater than 3584kB DETAIL: “max_stack_depth” must not exceed 3584kB. Looking at the source code it appears that the maximum stack limit is hard coded as 4194304 bytes for Windows builds. My query is why this number was picked? Is it to do with the maximum size the Windows Kernel will allow? Could I just increase the number and re-compile, or would that break other things? Paul
Re: Hard max_stack_depth / WIN32_STACK_RLIMIT PostgreSQL Windows Query
Paul Turton writes: > Looking at the source code it appears that the maximum stack limit is hard > coded as 4194304 bytes for Windows builds. My query is why this number was > picked? Is it to do with the maximum size the Windows Kernel will allow? > Could I just increase the number and re-compile, or would that break other > things? A bit of "git blame" archaeology says that that traces back to commit bf7737a938827608ce79586efe55c642c1a4a7d3 Author: Tom Lane Date: Wed Jan 26 21:55:26 2005 + On Windows, set the postmaster executable's stack size to 4MB, so that it agrees with the default value of max_stack_depth. So yeah, you could probably increase it in a custom build. However, I question a bit why you think you need to. IME hardly anyone ever fools with max_stack_depth, on any platform. regards, tom lane
