-----Original Message----- From: pgsql-bugs-ow...@postgresql.org [mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Tom Lane Sent: vrijdag 1 mei 2009 17:46 To: Mark Kramer Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #4787: Hardlink (ln) causes startup failure with bizarre "timezone_abbreviations" error
"Mark Kramer" <r...@asarian-host.net> writes: > > I have my PostgreSQL installed in /usr/local/PostgreSQL/ (cleaner for > > updates, instead of just /usr/local) As a result, I made hard-links > > like this, > > cd /usr/local/bin/ > > ln /usr/local/PostgreSQL/bin/pg_ctl pg_ctl > This isn't going to work because pg_ctl assumes it can find postgres in > the same directory it is in. Try using a symlink instead. (It'll be > less likely to fail miserably after an upgrade, too.) I tried a symlink as well. Then pg_ctl *can* start the server (which is kinda odd, by itself, that it can do so now, whereas not with a hardlink; unless pg_ctl actually reads the symlink content, which is very unlikely), but it reports a spurious error nonetheless: "could not start server" (whilst it DOES start the server just fine). As for pg_ctl assuming it can find postgres in the same directory it is in, it SHOULD. :) Basically, I hard-linked all files in /usr/local/PostgreSQL/bin/ to /usr/local/bin/. So, even when pg_ctl got started from /usr/local/bin/, it should have found /usr/local/bin/postgres right under its very nose! Also, the error message actually DOES seem to come from postgres (postgres[9742]: [6-1] FATAL), but that may well be an optical illusion on my end (as pg_ctl could log as 'postgres' too: haven't examined that yet). Clearly, seems PostgreSQL just really wants to be started from its original install-location. > > I get this error, though: > > May 1 04:40:26 asarian-host postgres[9742]: [6-1] FATAL: invalid > > value for parameter "timezone_abbreviations": "Default" > I agree this is an odd error message though. Perhaps you hardlinked a > few other things you didn't tell us about? I'm not sure what it would > take to make this be the first complaint. What is probably happening is > that postgres is trying to find /usr/local/PostgreSQL/share/ relative > to itself, but I'd have thought it would notice the problem sooner. The /share/ thingy is what I strongly suspected too; but since the bug report FAQ strongly discourages one from writing your assumptions about what you *think* might be the issue, I refrained from mentioning it. :) But yes, that seems like a logical place to look. - Mark -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
