Running the latest version (6.1.1) of the postgresql Chef cookbook (https://supermarket.chef.io/cookbooks/postgresql) with
node.default['postgresql']['enable_pgdg_yum'] = 'true'
node.default['postgresql']['version'] = '9.3'
This installs postgresql in /var/lib/pgsql/9.3, but running
psql -V
returns
psql (PostgreSQL) 9.2.33
You have to overwrite more at least version, dir, client, contrib and server packages:
node.default["postgresql"]["version"] = "9.3"
node.default["postgresql"]["dir"] = "/etc/postgresql/9.3/main"
node.default["postgresql"]["client"]["packages"] = ["postgresql-client-9.3", "libpq-dev"]
node.default["postgresql"]["server"]["packages"] = ["postgresql-9.3"]
node.default["postgresql"]["contrib"]["packages"] = ["postgresql-contrib-9.3"
It is just an example, I am not sure about package names, double check it. It is due to the way ruby evaluates strings.
Related
I'm installing Bucardo to replicate my Postgres server (10.1) on openSUSE Leap 42.3, and I have successfully complied the executable of Bucardo. When I tried bucardo install and modified the parameter as:
host:<none>
port:5432
user:aSuperUser
database:bucardo
piddir:/tmp/bucardo (already created)
Bucardo says: Postgres version is 4.8. Bucardo requires 8.1 or higher. How could this happen? I installed postgres 10, not 4.8. I also verified the version by select version(); and, there is only one postgres installation on my machine.
It seems to be fixed in master. There is a thread in the bucardo-general mailing list, that explains that you can make by yourself a couple of changes in the bucardo script or apply the diff:
diff --git a/bucardo b/bucardo index e1816f1..8e433ef 100755
--- a/bucardo
+++ b/bucardo ## -8979,7 +8979,7 ## sub install {
}
}
- if ($res !~ /(\d+)\.(\d+)(\S+)/) {
+ if ($res !~ /(\d+)\.(\d+)/) {
print "-->Sorry, unable to connect to the database\n\n";
warn $delayed_warning;
exit 1 if $bcargs->{batch}; ## -8988,10 +8988,7 ## sub install {
## At this point, we assume a good connection
## Assign the version variables
- my ($maj,$min,$rev) = ($1,$2,$3);
- ## We need to be able to handle things such as 9.2devel
- $rev =~ s/^\.//;
- $rev =~ s/(\d+)\.\d+/$1/;
+ my ($maj,$min) = ($1,$2);
$QUIET or print "Postgres version is: $maj.$min\n";
The bucardo script is in /usr/local/bin/bucardo and does not have write permissions so you must change it.
After an upgrade from Ubuntu Server 14.04 to 16.04 I had to also upgrade my Postgres clusters from 9.3 to 9.5. The normal way to do that is to first drop the (empty) 9.5 cluster that the upgrade created:
# pg_dropcluster 9.5 main
and then to upgrade the old 9.3 cluster to 9.5:
# pg_upgradecluster 9.3 main
This however results in an error:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US.UTF-8",
LC_ALL = (unset),
LC_PAPER = "nl_NL.UTF-8",
LC_ADDRESS = "nl_NL.UTF-8",
LC_MONETARY = "nl_NL.UTF-8",
LC_NUMERIC = "nl_NL.UTF-8",
LC_TELEPHONE = "nl_NL.UTF-8",
LC_IDENTIFICATION = "nl_NL.UTF-8",
LC_MEASUREMENT = "nl_NL.UTF-8",
LC_TIME = "nl_NL.UTF-8",
LC_NAME = "nl_NL.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
Error: The locale requested by the environment is invalid.
Error: Could not create target cluster
This means I could not upgrade to Postgres 9.5.
I checked all locale settings:
the en_US.UTF-8 locale exists and is properly generated as checked with locale -a (it shows en_US.utf8 in its list)
The file /etc/environment contains LC_ALL=en_US.UTF-8 and LANG=en_US.UTF-8
/etc/default/locale contains the same setting for LANG, LANGUAGE and LC_ALL
I can start Perl without any issue using "perl -e exit"
The error message is generated from the pg_createcluster script which is called from pg_updatecluster. But running pg_createcluster from the command line works just fine, without any issue.
Workaround for the issue:
I used the following workaround to at least get the conversion to work. I edited the /usr/bin/pg_upgradecluster script, as follows:
Find the code where it calls pg_createcluster by looking for the comment "create new cluster"
That code consists of a series of "push" statements, ending in the suspicious line:
delete $ENV{'LC_ALL'}
Notice that this LC_ALL is exactly the variable that is unset in the error message.
Comment out that delete comment by adding a '#' before it, then save.
This at least circumvents this problem and lets you run the upgrade.
My question: is this a bug in the pg_upgradecluster script, or is something else awry on my system?
had the same problem on an ubuntu 16.04 server. what helped in my case was to generate all the locales that appear in your listing of $ locale:
$ sudo locale-gen "en_US.UTF-8"
$ sudo locale-gen "nl_NL.UTF-8"
good luck!
In my case, it was complaining about
Error: The locale requested by the environment is invalid:
LANG: en_GB
LANGUAGE: en_GB:en
So I unset LANG and unset LANGUAGE and it worked.
For me, I have followed many suggestions and still didn't work.
The script mentioned
LC_TIME=en_UK but it's totally unrelated so I ignored it at first.
Turns out this was the problem and doing "unset LC_TIME" was all I needed.
Posting here in case it happened to someone else.
My quick way to disable that message: (macOS 12 Monterey M1)
Open Terminal -> Preferences -> Advanced tab -> uncheck to Set locale environment variables on startup
Just came across this in fresh Ubuntu + PostgresQL install, after all those years.. either way, the solution is:
apt-get install locales
I have the follow statements:
from alembic import op
conn = op.get_bind()
Now I want to get postgresql version.
According to documentation it is server_version property of connection:
conn = psycopg2.connect(settings.DB_DSN)
>>> conn.server_version
90504
The number is formed by converting the major, minor, and revision numbers into two-decimal-digit numbers and appending them together. For example, version 8.1.5 will be returned as 80105.
If you can run raw SQL queries, just run the following:
SELECT version();
If you are using ubuntu then you can execute command
psql -V
to check postgresql version where
V must be in capital.
and to check version of psycopg2 you can run following command
pip freeze | grep psycopg2
alternatively you can execute
pip freeze
to show all the installed packages with their respective version
import os
import psycopg2
conn_str = {
'user': os.environ['USERNAME'].lower(),
'host': 'POSTGES_SERVER_NAME',
'port': 5432,
'database': 'database_name'
}
conn = psycopg2.connect(**conn_str)
cursor = conn.cursor()
cursor.execute('SELECT VERSION()')
row = cursor.fetchone()
print(row)
cursor.close()
# output:
# ('PostgreSQL 10.1, compiled by Visual C++ build 1800, 64-bit',)
So this seems to be a really common problem with this setup, but I can't find any solutions that work on SO. I've setup a very new Ubuntu 15.04 server, then installed nginx, virtualenv (and -wrapper), and uWSGI (via apt-get, so globally, not inside the virtualenv).
My virtualenv is located at /root/Env/example. Inside of the virtualenv, I installed Django, then at /srv/www/example/app ran Django's startproject command with the project name example, so I have vaguely this structure:
-root
-Env
-example
-bin
-lib
-srv
-www
-example
-app
-example
manage.py
-example
wsgi.py
...
My example.ini file for uWSGI looks like this:
[uwsgi]
project = example
plugin = python
chdir = /srv/www/example/app/example
home = /root/Env/example
module = example.wsgi:application
master = true
processes = 5
socket = /run/uwsgi/app/example/example.socket
chmod-socket = 664
uid = www-data
gid = www-data
vacuum = true
But no matter whether I run this via uwsgi --ini /etc/uwsgi/apps-enabled/example.ini or via daemon, I get the exact same error:
Python version: 2.7.9 (default, Apr 2 2015, 15:37:21) [GCC 4.9.2]
Set PythonHome to /root/Env/example
ImportError: No module named site
I should note that the Django project works via the built-in development server ./manage.py runserver, and that when I remove home = /root/Env/example the thing works (but is obviously using the global Python and Django rather than the virtualenv versions, which means it's useless for a proper virtualenv setup).
Can anyone see some obvious path error that I'm not seeing? As far as I can tell, home is entirely correct based on my directory structure, and everything else in the ini too, so why is it not working with this ImportError?
In my case, I was seeing this issue because the django app I was trying to run was written in python 3 whereas uwsgi was configured for python 2. I fixed the problem by:
recompiling uwsgi to support both python 2 and python 3 apps
(I followed this guide)
adding this to my mydjangoproject_uwsgi.ini:
plugins = python35 # or whatever you specified while compiling uwsgi
For other folks using Django, you should also make sure you are correctly specifying the following:
# Django dir that contains manage.py
chdir = /var/www/project/myprojectname
# Django wsgi (myprojectname is the name of your top-level project)
module = myprojectname.wsgi:application
# the virtualenv you are using (full path)
home = /home/ubuntu/Env/mydjangovenv
plugins = python35
As #Freek said, site refers to a python module.
The error claims that python cannot find that package, which is because you have specified python_home to the wrong location.
I've encountered with the same problem and my uwsgi.ini is like below:
[uwsgi]
# variable
base = /home/xx/
# project settings
chdir = %(base)/
module = botservice.uwsgi:application
home = %(base)/env/bin
For this configuration uwsgi can find python executable in /env/bin but no packages could be found under this folder. So I changed home to
home = %(base)/env/
and it worked for me.
In your case, I suggest digging into home directive and point it to a location which contains both python executable and packages.
The site module is in the root of django.
First check is to activate the virtualenv manually (source /root/Env/example/bin/activate, start python and import site). If that fails, pip install django.
Assuming that django is correctly installed in the virtualenv, make sure that uWSGI activates the virtualenv. Relevant uWSGI configuration directives:
plugins = python
virtualenv = /root/Env/example
and in case you have error importing example.wsgi:
pythonpath = /srv/www/example/app/example
Env: CentOS 6.5, Chef, Vagrant, Berkshelf
Added cookbook "postgresql" in my Berksfile
Ran $ berks install followed berks upload which uploaded my cookbook to my hosted Enterprise Chef server.
Added my postgresql attributes to my cookbook my_cookbook/attributes/default.rb
default['postgresql']['version'] = '9.2'
default['postgresql']['client']['packages'] = ["postgresql#{node['postgresql']['version'].split('.').join}-devel"]
default['postgresql']['server']['packages'] = ["postgresql#{node['postgresql']['version'].split('.').join}-server"]
default['postgresql']['contrib']['packages'] = ["postgresql#{node['postgresql']['version'].split('.').join}-contrib"]
default['postgresql']['dir'] = "/var/lib/pgsql/#{node['postgresql']['version']}/data"
default['postgresql']['server']['service_name'] = "postgresql-#{node['postgresql']['version']}"
In my default.rb recipe:
include_recipe 'postgresql::yum_pgdg_postgresql'
include_recipe 'postgresql::server'
The Error:
Recipe: postgresql::client
* package[postgresql92-devel] action install
* No version specified, and no candidate version available for postgresql92-devel
================================================================================
Error executing action `install` on resource 'package[postgresql92-devel]'
================================================================================
I resolved this by adding one line in the my attributes/default.rb
default['postgresql']['enable_pgdg_yum'] = true <==== ADDED THIS
default['postgresql']['version'] = '9.2'
default['postgresql']['client']['packages'] = ["postgresql#{node['postgresql']['version'].split('.').join}-devel"]
default['postgresql']['server']['packages'] = ["postgresql#{node['postgresql']['version'].split('.').join}-server"]
default['postgresql']['contrib']['packages'] = ["postgresql#{node['postgresql']['version'].split('.').join}-contrib"]
default['postgresql']['dir'] = "/var/lib/pgsql/#{node['postgresql']['version']}/data"
default['postgresql']['server']['service_name'] = "postgresql-#{node['postgresql']['version']}"