aptible / docker-postgresql Goto Github PK

Postgres 9.4 introduced something called "dynamic shared memory". initdb selects a type (posix, sysv, etc.) for this parameter if it isn't specified. On older versions of Docker, Postgres selects 'sysv' on AWS instances, which leads to an error that looks like this during initialization:

FATAL: could not open shared memory segment "/PostgreSQL.1804289383": Permission denied ... failed!

I can't recreate this with Docker 1.5; it selects 'posix' for me and seems to work thereafter. Here's an email thread that discusses the issue and lists some possible workarounds, including mounting /dev/shm into the container. I tried to build this image with dynamic_shared_memory_type = 'none' in the config to disable it entirely but that didn't seem to take, because initdb still selected 'posix' for me.

• If there is a cert already use it.
• If not, use the ENV.
• If no ENV, use an auto-generated one.

Is there any downside to including this? If we don't it requires a server restart to enable.

This is a very usefull extension also many aplications are developed with this extension as requeriment including mine. Hope you can add this feature to your platform.

Link:
https://github.com/plv8/plv8

Also this extension is supported in heroku this is the link maybe help with this implementation.
https://blog.heroku.com/archives/2013/6/5/javascript_in_your_postgres

Thanks

Despite our tests for wal2json, it is not being installed on our image. find / -name *wal2json* produces no results whereas, when I manually installed it in a container, there was a /usr/lib/postgresql/10/lib/wal2json.so library. When I manually run the test SELECT 'init' FROM pg_create_logical_replication_slot('test_slot', 'wal2json');, I get the following error and an exit status of 1: ERROR: could not access file "wal2json": No such file or directory.

Zendesk Ticket: https://aptible.zendesk.com/agent/tickets/19593

This would enable remote monitoring via https://github.com/markwkm/pg_top.

Thanks for providing this useful container.

I am doing a research on configuration and have a question about two postgre config: It seems you keep the default setting of checkpoint_segments to 5min and checkpoint_completion_target to 0.5.

However, The official document recommends to set checkpoint_segments to at least 10, which improves the performance: "Unless you're running on a very small configuration, you'll almost certainly be better setting this to at least 10, which also allows usefully increasing the completion target."

The document also recommends to set checkpoint_completion_target to 0.9, which is the more useful value and improves the performance: "You can spread those writes out further, lowering the average write overhead, by increasing the checkpoint_completion_target parameter to its useful maximum of 0.9"

Shall we change the default of checkpoint_segments to 10 and checkpoint_completion_target to 0.9 for better performance?
Thanks.

Documentation site says I can find a list of extensions here in this repo. I was hoping to learn what the minimal number of extensions installed with the default image are, but I can't find it.

Enclave supports two families of images for Postgres: default and contrib.
The default images have a minimal number of extensions installed, but do include PostGIS.
The alternative contrib images have a larger number of useful extensions installed. The list of available extensions is visible in the repository we use to manage those images: aptible/docker-postgresql.

Is this documented anywhere? I need to know if I can use uuid-ossp on the default image. I can't find the string anywhere in the entire repo, but it has been an extension since at least PG 8 and is a fairly common use case now (generating / storing UUID data).

https://quay.io/repository/aptible/postgresql/build?current=99d8b4ac-aa10-4898-9596-4984f4a7d4dd

---> Running in 162539473c9d
1..9
ok 1 It should have Bats installed
ok 2 Bats should be v0.3.1
ok 3 It should install an OpenSSL version protected from CVE-2014-0160
ok 4 It should install a libssl version protected from CVE-2014-0160
ok 5 It should install PostgreSQL 9.3.4
not ok 6 It should protect against CVE-2014-0160
# (from function `install-heartbleeder' in file /tmp/test/postgresql.bats, line 12,
# in test file /tmp/test/postgresql.bats, line 27)
# * Starting PostgreSQL 9.3 database server
# ...done.
# --2014-04-30 23:26:20-- http://gobuild.io/github.com/titanous/heartbleeder/master/linux/amd64
# Resolving gobuild.io (gobuild.io)... 106.186.17.35
# Connecting to gobuild.io (gobuild.io)|106.186.17.35|:80... connected.
# HTTP request sent, awaiting response... 307 Temporary Redirect
# Location: http://gobuild-io.qiniudn.com/c22ea1d7-4af7-42f2-a92f-dd1367016938/heartbleeder-linux-amd64-master.zip [following]
# --2014-04-30 23:26:21-- http://gobuild-io.qiniudn.com/c22ea1d7-4af7-42f2-a92f-dd1367016938/heartbleeder-linux-amd64-master.zip
# Resolving gobuild-io.qiniudn.com (gobuild-io.qiniudn.com)... 38.125.163.141, 38.125.163.139
# Connecting to gobuild-io.qiniudn.com (gobuild-io.qiniudn.com)|38.125.163.141|:80... connected.
# HTTP request sent, awaiting response... 502 Bad Gateway
#2014-04-30 23:26:23 ERROR 502: Bad Gateway.
#
# * Stopping PostgreSQL 9.3 database server
# ...done.
ok 7 It should require a password
ok 8 It should use UTF-8 for the default encoding
ok 9 It should support PostGIS
The command [/bin/sh -c bats /tmp/test] returned a non-zero code: 255

Not sure if this can/should be addressed server-side...

cc: @dleve123