While following installation instructions (e.g., for caffe for os x), I run into the --fresh flag for homebrew. For example,
brew install --fresh -vd snappy leveldb gflags glog szip lmdb
However, I see no documentation about what --fresh does, and I don't find it in the source code for homebrew. What does this flag do? (Or what did it used to do?)
I found an old github issue describing the behavior of --fresh.
The flag was meant to ensure packages would be installed without any previously set compile-time options (like --with-python), but it was removed because it didn't do anything:
commit 64744646e9be93dd758ca5cf202c6605accf4deb
Author: Jack Nagel <jacknagel#gmail.com>
Date: Sat Jul 5 19:28:15 2014 -0500
Remove remaining references to "--fresh"
This option was removed in 8cdf4d8ebf439eb9a9ffcaa0e455ced9459e1e41
because it did not do anything.
Related
My company has a legacy, internal server running CentOS 6.4 with postgreSQL 8.4.13. The goal is to upgrade it as far as possible without doing OS updates; it's a live internal server being used for services, so it's not practical to upgrade the OS or have a long downtime. It's old and doesn't follow best practices at all, but unfortunately, this is what I have to work with.
Using the CentOS vault, I can use the base repo to upgrade to 8.4.20.
I can also add and access the pgdg archive repos (for 8.4.22 and up), but they're not included in the CentOS postgresql group and install separately from the default CentOS installation.
I've tried doing that anyway with postgreSQL 8.4.22 as an initial small stop (since "minor" versions < 10 were actually major releases) and pg_upgrade fails with:
The old cluster lacks some required control information:
latest checkpoint oldestXID
If I check pg_controldata, I get
pg_control version number: 843
Catalog version number: 200904091
Database system identifier: 5893982526456722425
Database cluster state: in production
pg_control last modified: Sat 05 Mar 2022 04:35:52 PM JST
Latest checkpoint location: 278A/6517F558
Prior checkpoint location: 278A/6517F510
Latest checkpoint's REDO location: 278A/6517F558
Latest checkpoint's TimeLineID: 1
Latest checkpoint's NextXID: 7/1001247883
Latest checkpoint's NextOID: 260730376
Latest checkpoint's NextMultiXactId: 1
Latest checkpoint's NextMultiOffset: 0
Time of latest checkpoint: Sat 05 Mar 2022 04:35:40 PM JST
Minimum recovery ending location: 0/0
Maximum data alignment: 8
Database block size: 8192
Blocks per segment of large relation: 131072
WAL block size: 8192
Bytes per WAL segment: 16777216
Maximum length of identifiers: 64
Maximum columns in an index: 32
Maximum size of a TOAST chunk: 1996
Date/time type storage: 64-bit integers
Float4 argument passing: by value
Float8 argument passing: by value
There's clearly no reference to latest checkpoint oldestXID in it.
I looked at the changelogs for 8.4.21 and 8.4.22, but there are no references to "oldestXID". I've also tried, using a backup server, pg_resetxlog -f /var/lib/pgsql/data, which yields the same pg_control file without latest checkpoint oldestXID.
I realize that these are all incredibly old versions, but that just means I'm doubly lost here. I hope someone has some ideas, because I'm all out.
So, my friend asked me if I'd gone through the old source code looking for references, and I realized I hadn't because I hadn't been able to find the source. I looked around a bit more and found the source at https://www.postgresql.org/ftp/source/ -- in hindsight, very obvious.
I went through the source code from 8.4.13 up to 9.0.0 looking for "XID" in pg_controldata.c. It turns out that 9.0.0 added this field and later versions don't support migrating without it.
[pgdg90]
name=PostgreSQL 9.0 RPMs for RHEL/CentOS 6
baseurl=https://yum-archive.postgresql.org/9.0/redhat/rhel-6-x86_64
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG
I added this repo to /etc/yum/repos.d and then checked the available versions with yum --showduplicates list postgresql90 -- the earliest available version was 9.0.6.
I shut down postgresql and installed 9.0.6 with yum install postgresql90-server-9.0.6-1PGDG.rhel6 postgresql90-devel-9.0.6-1PGDG.rhel6 postgresql90-libs-9.0.6-1PGDG.rhel6.
Strangely enough, pg_upgrade didn't actually exist in /usr/pgsql-9.0/bin... so a quick yum whatprovides '*pg_upgrade' | grep 9.0.6 showed me that I actually had to install postgresql90-contrib-9.0.6-1PGDG.rhel6.x86_64 as well.
I added /usr/pgsql-9.0/bin to my $PATH, ran initdb, ran pg_upgrade with --check, and all seemed well. I grabbed the settings I needed from the old postgresql.conf and pg_hba.conf and copied them to the 9.0 conf files, ran pg_upgrade, and everything went smoothly.
After checking basic operations, database integrity, and functions with the web apps we have, I went ahead and did yum update postgresql90 to update to the latest minor minor version in pgdg (9.0.23, in this case) and that went swimmingly as well.
So, if anyone else happens to find this niche problem, that's how you can try dealing with it. Best of luck!
So ive been tasked of upgrading our postgres server to version 11, however all the guide ive found either dont work for me or are not complete.
I have tried 2 methods and had to recall all changes:
https://www.hutsky.cz/blog/2019/02/upgrade-postgresql-from-9-3-to-11/
In this method not only are the dependency checks and upgrade commands exactly the same but also none of these commands work for me, i keep getting the error of:
"You must identify the directory where the new cluster binaries reside.
Please use the -B command-line option or the PGBINNEW environment variable.
Failure, exiting"
And ive been unable to find any fix to this.
And also tried the delete old method :
https://techcyclist.com/postgres/upgrading-postgres-to-the-latest-version-on-centos-7-server/
but in this method he deletes the old postgres completely and also the config files, but our config files have been made by the EX sys admin and i simply dont have the time it takes to study the configs to redo them in the new version, and i cant risk simply replacing the new config file with the ole one.
If anyone has done such a assignment and is willing to help, i would much appreciate it.
I used : yum install postgresql11 postgresql11-contrib postgresql11-devel postgresql11-libs postgresql11-server
to install the new postgres 11 and :
/usr/pgsql-11/bin/initdb -D /var/lib/pgsql/11/data
to init it. with a few dependencies installing in between.
afterwards all other commands :
/usr/pgsql-11/bin/pg_upgrade --old-bindir=/usr/pgsql-9.3/bin/ --
new-bindir=/usr/pgsql-11/bin/ --old-
datadir=/var/lib/pgsql/9.3/data/ --new-
datadir=/var/lib/pgsql/11/data/ --check
gave errors as described.
I'm struggling with connecting to Impala which is part of a kerberised CDH cluster via JDBC driver. For authentication I need to acquire a Kerberos ticket on my machine. kinit works like a charm. The strange is that, when I setup KRB5CCNAME variable pointing to a file the file remains empty after successful authentication, but klist shows that I'm authenticated. Is it the expected behaviour?
The reason I ask this is that, my java app can't connect to Impala and the error message suggest that the empty file could be the problem. However, a python script can connect to the same Impala from the same machine.
It is a Mac 2018.
It shouldn't.
Apple has its own bundled kerberos implementation (Heimdal) which does this strange empty file thing.
I installed krb5 package from brew, modified the PATH accordingly and it works fine.
myself#mymachine:~$ brew info krb5
krb5: stable 1.16.2 (bottled) [keg-only]
Network authentication protocol
https://web.mit.edu/kerberos/
/usr/local/Cellar/krb5/1.16.2 (160 files, 3.7MB)
Poured from bottle on 2018-12-18 at 15:20:46
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/krb5.rb
==> Dependencies
Required: openssl ✔
==> Caveats
krb5 is keg-only, which means it was not symlinked into /usr/local,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.
If you need to have krb5 first in your PATH run:
echo 'export PATH="/usr/local/opt/krb5/bin:$PATH"' >> ~/.bash_profile
echo 'export PATH="/usr/local/opt/krb5/sbin:$PATH"' >> ~/.bash_profile
For compilers to find krb5 you may need to set:
export LDFLAGS="-L/usr/local/opt/krb5/lib"
export CPPFLAGS="-I/usr/local/opt/krb5/include"
For pkg-config to find krb5 you may need to set:
export PKG_CONFIG_PATH="/usr/local/opt/krb5/lib/pkgconfig"
==> Analytics
install: 198 (30 days), 614 (90 days), 1,986 (365 days)
install_on_request: 182 (30 days), 557 (90 days), 1,768 (365 days)
build_error: 0 (30 days)
myself#mymachine:~$ /usr/bin/klist --version
klist (Heimdal 1.5.1apple1)
Copyright 1995-2011 Kungliga Tekniska Högskolan
Send bug-reports to heimdal-bugs#h5l.org
Similar issue will arise on Windows, where Kerberos does not respect whether KRB5CCNAME environment variable is set or not. The solution for this is using older version. This page mentions 4.0.1 version, however on the Kerberos page you can find 4.1. The first will use file cache, the latter will use API and pretty difficult to ask it not to use it.
During upgrade from PostgreSQL 8.4.8 to PostgreSQL 9.5.2 on Windows OS, i got the following error over command line:
Running in verbose mode
cannot write to log file pg_upgrade_internal.log
Failure, exiting
When I checked the file pg_upgrade_internal.log, it contained following data:
Running in verbose mode
-----------------------------------------------------------------
pg_upgrade run on Tue Apr 24 17:02:13 2018
-----------------------------------------------------------------
Other files like pg_upgrade_server.log , pg_upgrade_utility.log, pg_upgrade_server_start.log, which are generated by pg_upgrade utility, also contain partial data:
-----------------------------------------------------------------
pg_upgrade run on Tue Apr 24 17:02:13 2018
-----------------------------------------------------------------
If pg_upgrade utility failed to write (or in other words, did not have permission), then who wrote the above data ? I am sure that these logs were written by PostgreSQL utility only.
BTW, I have already checked the Stackoverflow, PostgreSQL site links (link1, link2, etc.) which describe the cannot write... error issue, but none of those links mention this issue/concern.
Adding this for reference even though the question is old.
I had the same problem as above and none of the solutions seemed to work.
In my case it seems that the issue was caused by using the machines "Administrator" user with a elevated cmd prompt. I "fixed" the problem by using a normal user, with the correct security permissions on the Postgres data directories.
I am trying to install RMySQL on my Windows 7 Professional x64 machine using R-2.15.1, RTools 2.16 (also tried 2.15), and MySQL 5.5.
I have copied libmysql.dll and libmysql.lib into mysql\lib\opt and \bin. I have also copied libmysql.dll into R-2.15.1\bin.
I have set Renviron.site properly as confirmed by Sys.getenv('MYSQL_HOME') using both the 8.3 nomenclature as well as non-8.3 nomenclature.
Sample output for Sys.getenv('MYSQL_HOME') is "C:/Program Files/MySQL/MySQL Server 5.5/" (quotes included). When I use 8.3 nomenclature it also is correct.
Here is the relevant part of my PATH:
c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;C:\Program Files\MySQL\MySQL Server 5.5\lib\opt;c:\program file\R\R-2.15.1\bin;
I have manually inserted it into the registry in the right location (because the MySQL 5.5 doesn't do that properly - it only puts it under the Wow6432Node) AND I inserted it into the system variables to deal with this error:
Error in utils::readRegistry("SOFTWARE\MySQL AB", hive = "HLM", maxdepth = 2) :Registry key 'SOFTWARE\MySQL AB' not found
I even tried
Sys.setenv('MYSQL_HOME=C:/Program Files/MySQL/MySQL Server 5.5/')
However, when I try to install RMySQL I get the following error:
checking for $MYSQL_HOME... not found... searching registry...
cygwin warning:
MS-DOS style path detected: C:/PROGRA~1/R/R-215~1.1/bin/x64/Rscript
Preferred POSIX equivalent is: /cygdrive/c/PROGRA~1/R/R-215~1.1/bin/x64/Rscript
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
Try setting MYSQL_HOME to one of the following (you may have to use the non-8dot3 file name):
ERROR: configuration failed for package 'RMySQL'
If I am understanding the error properly, it can't find MYSQL_HOME, even though it calls it properly using Sys.getenv, is located in the proper location in the registry, AND is a system variable.
I have a similar issue with my Windows 7 x64 installation.
I think the problem is not related to the MYSQL_HOME, but to the registry.
As you can see here:
https://dev.mysql.com/doc/refman/5.1/en/windows-install-wizard.html
the default location for the registration is not SOFTWARE\MySQL AB but SOFTWARE\Wow6432Node\MYSQL AB.
I believe the answer is here:
http://martin.von-gagern.net/howtos/20110728-rmysql/