can't set data_directory in config about postgresql HOT 11 CLOSED

+1, experiencing similar pg-restart-fail issue using chef cookbook via opsworks.

similar old tickets

• https://tickets.opscode.com/browse/COOK-1632
• https://tickets.opscode.com/browse/COOK-3618

from postgresql.

particularly of concern, as in our environment this failure occurs when an instance 'auto-heals' (i.e. building new instance). will report if we find a fix.

from postgresql.

Posted my work around at: https://tickets.opscode.com/browse/COOK-1632

from postgresql.

So I ran into the same problem and adapted robdbirch's opscode response into some chef code. It's not the greatest, because I assume the cluster name to be "main" and also assumed pg_createcluster is in /usr/bin. However, things like node[:postgresql][:dir] also assume the name to be main.

This is in server.rb, starting at line 61

# Create the database directory if you used a custom database dir
execute "Create PGDATA" do
  command "/usr/bin/pg_createcluster -D #{node['postgresql']['config']['data_directory']} #{node['postgresql']['version']} main"
  not_if { ::File.exists?(node['postgresql']['config']['data_directory']) }
end

The reason it has to be at line 61 is because it'll create the /etc/postgresql/9.3/main directory that is used for the following 2 template statements.

So maybe the answer overall is to create a default['postgresql']['cluster_name'] attribute set to "main", and then set the dir to be based off the cluster name

default['postgresql']['dir'] = "/etc/postgresql/#{node['postgresql']['version']}/#{node['postgresql']['cluster_name']"

That way you can also use the cluster_name attribute in the create cluster command.

Not a huge postgres user, so I also don't know if this breaks in the case of a database restore like bmishkin brought up.

from postgresql.

I ran into this issue as well and made a work around for this that is Debian specific. It basically just copies the initial database metadata installed by the Debian package manager (from the default path) to the one specified by the node['postgresql']['config']['data_directory] attribute. Not the most elegant solution, but it works for my uses cases.

I submitted PR #174 just in case the core team likes the solution or chooses to improve on it.

from postgresql.

Along the lines of PR #174 we put the code in a wrapper cookbook and used 'package' to install postgresql first before doing data copies and then handing off to the community cookbook.

#
# Cookbook Name: sbo_postgresql
# Recipe: server
# Installs the postgresql server.
#

# Install Postgresql from apt repos first.
include_recipe 'apt'

node['postgresql']['server']['packages'].each do |pg_pack|
    package pg_pack
end

# Now that postgresql is installed we can create our directory that we want, set the user/group perms
# and copy the data over from the default data_directory to our custom data_directory.

directory node['postgresql']['config']['data_directory'] do
  recursive true
  owner 'postgres'
  group 'postgres'
  mode '0700'
  notifies :run, 'ruby_block[moving data directory]', :immediately
end

ruby_block "moving data directory" do
  block do
    FileUtils.cp_r(Dir["/var/lib/postgresql/#{node['postgresql']['version']}/main/*"], \
                   node['postgresql']['config']['data_directory'], :preserve => true)
  end
  only_if { Dir["#{node['postgresql']['config']['data_directory']}/*"].empty? }
  action :nothing
end

# Now run the community cookbook.
include_recipe "postgresql::server"

from postgresql.

I ran across this same issue, and tried the solution above.

However, I found this didn't work well: I ended up copying a corrupted postgres data store / postgres complained it wasn't shut down properly. Which makes sense, after all: this copy does just yank the files out from under postgres in a non-atomic way.

SOOOOO

My solution was to stop the postgres service right after installation, do the server config, run initdb if we have to, then start the server back up.

It doesn't copy the data from the previous location, which is fine by me. I suppose I could have stopped the server, run the copy ruby_block above, then restarted the server... but, eh? I'm a newbie postgres admin, but maybe there's something to be said about starting fresh (like if you set the character set in the config file or something??????). Or maybe rerunning initdb is silly... ❓ ❔

Anyway, my changes to server_debian are below. I could probably submit a PR for this, or at least this may help future searchers.

node['postgresql']['server']['packages'].each do |pg_pack|
  package pg_pack
end

# stop the service, because the pg daemon saves the pid file in the data folder...
# and we may change the data file...
# RPW 03-03-2015
# ARRGHH. See: https://github.com/hw-cookbooks/postgresql/pull/174

service "postgresql" do
  service_name node['postgresql']['server']['service_name']
  action :stop
end

include_recipe "postgresql::server_conf"


# we may need to rerun initdb especially if we're startig from 0. RPW 03-04-2015
execute "/usr/lib/postgresql/#{node['postgresql']['version']}/bin/initdb -D #{node['postgresql']['config']['data_directory']}" do
  not_if { ::FileTest.exist?(File.join(node['postgresql']['config']['data_directory'], "PG_VERSION")) }
  user "postgres"
end

service "postgresql" do
  service_name node['postgresql']['server']['service_name']
  supports :restart => true, :status => true, :reload => true
  action [:enable, :start]
end

from postgresql.

An old one... soon to be corrected. #314

from postgresql.

Resolved as of release 4.0.0 - https://github.com/hw-cookbooks/postgresql/releases/tag/v4.0.0

from postgresql.

@slyness just tried this on a ubuntu 14.04 to see if 4.0.0 fixes the issue with the directory, however this issue still persists... : /

p.s. Happy New Year!! 🎉

from postgresql.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

from postgresql.