In order to patch RedHat 7 machines to version 7.9, I've created an RPM repository with RPMs extracted from a DVD.iso file of the patch (example source guide), and updated said machines using yum.
The patch has succeeded with many of the machines (RHEL 7.7 only), but the rest (7.0, 7.2 and some 7.7 as well) have failed the with the following error:
Error: requested datatype filelists not available
I've also tried to gradualize the process and patch the 7.0 and 7.2 ones to 7.7 first by the same process, but yielded the same result. I've made sure I got each and every file in the Packages folder.
It is rather puzzling for me that some succeed and some fail, especially those with the same version. But I'm assuming they were created differently as I don't have the information to say otherwise. So my best direction would be to go by the error.
In this github post, lr1980 says:
https://blog.packagecloud.io/eng/2015/07/20/yum-repository-internals/
this means the "filelists.xml.gz" is missing on repo => it's a packager.io problem
Indeed, browsing my repository's repodata folder reveals only other.xml.gz and primary.xml.gz files, which are also the only files pointed to in the repomd.xml.
I've tried uploading the filelists.xml.gz file from the dvd.iso and reindexing, but it gets removed (admittedly am not familiar with this area of knowledge.. at all). What does "it's a packager.io problem" mean?
How can I force the repo to have such a file, assuming that's what I need? Or what can I do to solve this issue otherwise?
Many thanks
I had a server set up as a subscriber to our production server using postgreSQLs new logical replication feature. It seemed to be working well, however yesterday I needed to install the postgresql10-contrib10.4-1 package.
Now, for some reason the subscription is broken and errors out when I try to resubscribe with the following error message:
ERROR: could not create replication slot "subrep1": ERROR: could not load library "/usr/pgsql-10/lib/pgoutput.so": /usr/pgsql-10/lib/pgoutput.so: undefined symbol: is_publishable_relation
SQL state: XX000
First off, is this an issue with the publisher or the subscriber? The subscriber is pg 10.4 and the publisher is pg 10.2.
Any idea what is going on?
Please check publishers binaries. Might be the case when binaries were updated but service wasn't restarted
Hope you are well.
I am trying to move a PostGIS data table from one server to another. I have installed postgresql on the target machine, configured it to allow sensible authentication (username/password). I have also used yum to install the postgis2_91 package (including debuginfo, devel, docs and utils).
When i initially tried to restore the sql dump to the target server i got a load of errors, i put this down to postgis not being installed as it was complaining about the "geometry" data type.
I believe i need to follow these instructions (from spatially enable database) http://trac.osgeo.org/postgis/wiki/UsersWikiPostGIS21CentOS6pgdg however, when i tried to run the command below I got an error saying "ERROR: must be owner of the spheroid", this is while I'm logged in as the "postgres" user which I believe has full permissions?
CREATE EXTENSION postgis;
Edit - I managed to fix this by completely removing postgres and postgis, then tried the procedure again and it worked. No idea why it didn't work but it is now resolved.
Any ideas?
Thanks
Paul
Jupitor$ bundle exec rake db:create db:migrate
APP_development already exists
rake aborted!
PG::Error: ERROR: invalid value for parameter "TimeZone": "UTC"
: SET time zone 'UTC'
I keep getting this error when trying to migrate to my postgres database.
help would be much appreciated!
I had the same problem using the Postgres.app from Heroku. Rebooting my Mac solved it.
Restarting postgresql works.
To restart if you've installed it using homebrew, brew info postgresql will tell you to:
launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
brew services restart postgresql
Try restarting the server. I updated Postgresql through Homebrew but forgot to restart the server and got this same problem. I believe it's due to the client and server versions not matching. psql started with:
$ psql
psql (9.1.4, server 9.1.2)
Type "help" for help.
Based on #MathiasJ's answer, instead of rebooting my entire machine, I ran
brew services restart postgresql#9.6
and my subsequent rake db:create worked perfectly.
I don't think I deserve any points for that but rebooting my Postgres.app (which is better than rebooting the whole system) solved it for me. The app doesn't show up on the Dock, you can find it on the navbar at the top of your window. Hope it helps anyway.
What actually happened is that you upgraded the postgresql server and cleaned-up your old folders but you haven't restarted your postgresql server. The server searched for the timezones files in the deleted dir
If nothing else fixes and you happen to be using homebrew, chances are you have issues with current links.
Assuming you have two Postgres versions installed, make sure you unlink and then link again. In my case, I needed the two versions working in order to run pg_upgrade. I have postgresql95 and postgresql so I did:
$ brew unlink postgresql
$ brew unlink postgresql95
$ brew link postgresql95
$ brew link --overwrite postgresql
That got me both working at same time. Hope it becomes helpful as it took me a good while to figure that out!
I also had this problem.
Login to the database then issue:
set time zone utc;
In my case restarting the database didn't help. Updating tzdata (apt-get install tzdata) did the trick for me.
just restarting the database helped. Homebrew updated my Postgres installation and I did not restart yet.
I had a similar problem after updating time zone information, that is, downloading the IANA database and compiling using zic.
My problem actually began after restarting PostgreSQL. I got invalid value for parameter TimeZone: UTC and restarting again did nothing to solve the problem.
It turns out my time zone information was completely messed up after the update. I had dangling symbolic links in /usr/share/zoneinfo. From a psql console, I got:
mydb=# SELECT * FROM pg_timezone_names;
ERROR: could not stat "/usr/share/zoneinfo/PRC": No such file or directory
I deleted all such dangling symlinks. After doing this, at least I could get SELECT * FROM pg_timezone_names to work, but still got the same invalid value... error.
What finally solved the problem for me was creating a new symlink:
cd /usr/share/zoneinfo
ln -s Etc/UTC UTC
After this, SET time zone 'UTC' worked correctly.
brew services restart postgresql did not fix for me. I'm sure rebooting would've worked, but I wanted to figure out the cause of the issue.
I believe the issue was caused for me because of two conflicting versions of postgresql.
I already had postgresql running with brew services, and then installed postgresql#11 which left postgresql running in brew services even after I uninstalled postgresql.
I fixed this by stopping the postgresql brew service, even though it wasn't listed in brew services list.
Steps to reproduce:
$ brew install postgresql
$ brew services start postgresql
$ brew install postgresql#11
$ brew uninstall postgresql
$ brew services start postgresql#11
How to fix:
$ brew services stop postgresql
Update: issue appears to have been deleted.
Opened an issue on Homebrew requesting that a formula's service should automatically be stopped upon uninstall.
Just a quick reference for those that are not using Postgres.app, but that start psql from the command line or through launchctl. You'll need to adjust the following for where you have your Postgres data and log files located at:
pg_ctl stop
pg_ctl start -D /usr/local/pgsql/data/ -l /usr/local/pgsql/log/server.log
For everyone using homebrew.
brew services restart postgresql did not fix for me too.
Rebooting fixed the issue. Thank you #JBallin, what you said is right.
Apparently, a similar thing also happens with Java/JDBC while connecting to Postgres.
The solution there is to tell JDBC to report the correct user timezone to Postgres while getting the connection.
So, explicitly mention the user timezone while starting the program helps:
java -Duser.timezone=America/Los_Angeles com.example.MyMainClass
Note:
Adding this here because this happens to be the first result on Google for this issue with connecting to Postgres!
Source:
This comment by Yuriy on the Jira support forum:
https://community.atlassian.com/t5/Jira-questions/invalid-value-for-parameter-quot-TimeZone-quot-quot-US-Pacific/qaq-p/839426
I'm trying to give pg_bulkload a try.
When I try to use the postgresql executable it provides, I get the following error:
/usr/local/src/pg_bulkload-3.0.1/bin> ./postgresql start -D /pg_data
server starting
/usr/local/src/pg_bulkload-3.0.1/bin>
FATAL: unrecognized configuration parameter "wal_level"
Google turned up an exact match for this error when someone was using a 9.0 version of psql to run a script on an instance of Postgres 8.4. I don't see how that could be related to my case--I have two versions of Postgres, but I'm sure I'm pointing at the right directory... any thoughts are very welcome.
As far as I can tell from the docs, PostgreSQL 9.x supports a configuration parameter named "wal_level", but version 8.4 does not. The postgresql.conf file for my 9.0.something server has that parameter; the one for my 8.4 server does not.
PostgreSQL 9.x server configuration
PostgreSQL 8.4 server configuration
Your error message suggests you're running version 8.4, but it's reading the configuration file for a 9.x server. Check your postgresql.conf and installation process. I'm thinking pg_bulkload might have "helped" you in ways you didn't anticipate.
I think that it can be a bit tricky to install pg_bulkload to the right place if you have more than one version of PostgreSQL installed on your machine. My first problem was that pg_bulkload (version 3.1.6) could not find pg_port library. I copied the library libpgport.a (a static library) to /usr/local/lib where it was found, but this approach is not recommended, because this is only a quick fix that doesn't work at the end. So, very soon there was another problem: "undefined reference to `pstrdup'". I reckon that in pg_bulkload there should be a possibility of pointing out where PostgreSQL is installed. Well, I changed Makefile of pg_bulkload in pg_bulkload-3.1.6/bin, namely line with PG_LIBS: PG_LIBS = $(libpq) -L/current location of your PostgreSQL/PostgreSQL/pgsql/lib -lpgport -lpgcommon. -lpgport has to be added before -lpgcommon. Last but not least, to compile and install pg_bulkload you shoud modify your PATH: PATH=/current location of your PostgreSQL/PostgreSQL/pgsql/bin:$PATH make USE_PGXS=1 [install]; This makes sure that your pg_bulkload will be added to the correct version of PostgreSQL (in my case 9.3). Enjoy!