Re: [BUGS] BUG #4787: Hardlink (ln) causes startup failure with bizarre "timezone_abbreviations" error
-Original Message-
From: pgsql-bugs-ow...@postgresql.org
[mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Tom Lane
Sent: vrijdag 1 mei 2009 23:57
To: Mark; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #4787: Hardlink (ln) causes startup failure with
bizarre "timezone_abbreviations" error
> What I'm inclined to do is modify PostmasterMain so that immediately
> after find_my_exec, it checks that get_share_path returns the name of
> a readable directory.
I understand the rationale for relocatable packages. So, I guess hardlinks
are out. But, barring hardlinks, perhaps, in the existence of a symlink, a
simple 'readlink' function could be done to auto-correct PostgreSQL's
base-location? Ala:
char buf[1024];
ssizet_t len;
if ((len = readlink ("/usr/local/bin/pg_ctl", buf, sizeof(buf)-1)) != -1)
buf[len] = '\0';
Symlinks are used quite often, *especially* when dealing with relocatable
packages (read: that will likely not reside in /usr/local/, etc.). And it
would only requires two or three extra lines of code, no?
At any rate, I appreciate you looking into this.
- Mark
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4787: Hardlink (ln) causes startup failure with bizarre "timezone_abbreviations" error
Mark writes: > I understand the rationale for relocatable packages. So, I guess hardlinks > are out. But, barring hardlinks, perhaps, in the existence of a symlink, a > simple 'readlink' function could be done to auto-correct PostgreSQL's > base-location? Ala: That's exactly what it already does, and why it would've worked if you'd used symlinks not hardlinks. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4763: postgres service unstable, even during install
On May 1, 12:41 pm, Kevin Field wrote: > On Apr 26, 2:08 pm, dp...@pgadmin.org (Dave Page) wrote: > > > On Fri, Apr 24, 2009 at 3:09 PM, Kevin Field > > wrote: > > > On Apr 24, 9:32 am, dp...@pgadmin.org (Dave Page) wrote: > > > >> I don't know if there is any way we can solve it, except by reverting > > >> back to 5.8 or advising users to use only one version. > > > > I just had an idea--at least in the ActiveState distributions (not > > > sure about Strawberry or Vanilla) they include versioned-filename > > > binaries. So you can launch perl5.8.8.exe or perl5.10.0.exe and as > > > long as it's in the path you get the exact right one. (As I found out > > > when I went to try to figure out per-user paths, I somehow have both > > > versions in the universal path.) Would that help? > > > No, because we use the DLLs, not the .exe. But they do seem to be > > versioned anyway, so there must be something else going on :-( > > :( Well on my end, I haven't been able to figure out how to get it to > see the right version. Do you know when the next beta or win32 > installer build might be out so I can try again? Through some testing today I determined: 1) the installer decides on whether you have Perl / where it is before the first opportunity to click 'back', so, right at the beginning. 2) if I rename my Perl 5.8 directory--whether or not I rename my Perl 5.10 directory--the installer cannot find it and does not present pl/ perl[u] as an option a few Next-clicks later. 3) if I rename my Perl 5.10 directory to where I had had my Perl 5.8 directory, it's still not presented as an option So...what, is it insisting on perl58.dll at the beginning of the install and then perl510.dll when it goes to actually use it? Let's see...i'll rename things back (so it'll be an option), select the pl/ perl options, and then rename the directories before clicking 'next'. Result: same errors when it goes to activate plperl and plperlu. I guess not. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4763: postgres service unstable, even during install
On May 2, 12:09 pm, Kevin Field wrote: > On May 1, 12:41 pm, Kevin Field wrote: > > > > > On Apr 26, 2:08 pm, dp...@pgadmin.org (Dave Page) wrote: > > > > On Fri, Apr 24, 2009 at 3:09 PM, Kevin Field > > > wrote: > > > > On Apr 24, 9:32 am, dp...@pgadmin.org (Dave Page) wrote: > > > > >> I don't know if there is any way we can solve it, except by reverting > > > >> back to 5.8 or advising users to use only one version. > > > > > I just had an idea--at least in the ActiveState distributions (not > > > > sure about Strawberry or Vanilla) they include versioned-filename > > > > binaries. So you can launch perl5.8.8.exe or perl5.10.0.exe and as > > > > long as it's in the path you get the exact right one. (As I found out > > > > when I went to try to figure out per-user paths, I somehow have both > > > > versions in the universal path.) Would that help? > > > > No, because we use the DLLs, not the .exe. But they do seem to be > > > versioned anyway, so there must be something else going on :-( > > > :( Well on my end, I haven't been able to figure out how to get it to > > see the right version. Do you know when the next beta or win32 > > installer build might be out so I can try again? > > Through some testing today I determined: > > 1) the installer decides on whether you have Perl / where it is before > the first opportunity to click 'back', so, right at the beginning. > 2) if I rename my Perl 5.8 directory--whether or not I rename my Perl > 5.10 directory--the installer cannot find it and does not present pl/ > perl[u] as an option a few Next-clicks later. > 3) if I rename my Perl 5.10 directory to where I had had my Perl 5.8 > directory, it's still not presented as an option > > So...what, is it insisting on perl58.dll at the beginning of the > install and then perl510.dll when it goes to actually use it? Let's > see...i'll rename things back (so it'll be an option), select the pl/ > perl options, and then rename the directories before clicking 'next'. > Result: same errors when it goes to activate plperl and plperlu. I > guess not. This is actually a bit worse than I thought--I can't ditch 5.8, then. I haven't tried a full uninstall of 5.8 and 5.10 and then installing 5.10 and then installing pgsql. I guess that's the next thing to try. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4763: postgres service unstable, even during install
On May 2, 12:11 pm, Kevin Field wrote: > On May 2, 12:09 pm, Kevin Field wrote: > > > > > On May 1, 12:41 pm, Kevin Field wrote: > > > > On Apr 26, 2:08 pm, dp...@pgadmin.org (Dave Page) wrote: > > > > > On Fri, Apr 24, 2009 at 3:09 PM, Kevin Field > > > > wrote: > > > > > On Apr 24, 9:32 am, dp...@pgadmin.org (Dave Page) wrote: > > > > > >> I don't know if there is any way we can solve it, except by reverting > > > > >> back to 5.8 or advising users to use only one version. > > > > > > I just had an idea--at least in the ActiveState distributions (not > > > > > sure about Strawberry or Vanilla) they include versioned-filename > > > > > binaries. So you can launch perl5.8.8.exe or perl5.10.0.exe and as > > > > > long as it's in the path you get the exact right one. (As I found out > > > > > when I went to try to figure out per-user paths, I somehow have both > > > > > versions in the universal path.) Would that help? > > > > > No, because we use the DLLs, not the .exe. But they do seem to be > > > > versioned anyway, so there must be something else going on :-( > > > > :( Well on my end, I haven't been able to figure out how to get it to > > > see the right version. Do you know when the next beta or win32 > > > installer build might be out so I can try again? > > > Through some testing today I determined: > > > 1) the installer decides on whether you have Perl / where it is before > > the first opportunity to click 'back', so, right at the beginning. > > 2) if I rename my Perl 5.8 directory--whether or not I rename my Perl > > 5.10 directory--the installer cannot find it and does not present pl/ > > perl[u] as an option a few Next-clicks later. > > 3) if I rename my Perl 5.10 directory to where I had had my Perl 5.8 > > directory, it's still not presented as an option > > > So...what, is it insisting on perl58.dll at the beginning of the > > install and then perl510.dll when it goes to actually use it? Let's > > see...i'll rename things back (so it'll be an option), select the pl/ > > perl options, and then rename the directories before clicking 'next'. > > Result: same errors when it goes to activate plperl and plperlu. I > > guess not. > > This is actually a bit worse than I thought--I can't ditch 5.8, then. > I haven't tried a full uninstall of 5.8 and 5.10 and then installing > 5.10 and then installing pgsql. I guess that's the next thing to try. Okay, I uninstalled both 5.8 and 5.10, installed 5.10 fresh, and it doesn't detect it during install. I tried another fresh install of 5.10 with PerlScript. Same deal. Now I'm trying a fresh install with all options checked. Still no dice. What exactly is it looking for? Has anybody had a successful install of ActiveState Perl 5.10 build 1004 followed by PostgreSQL 8.4-beta1 with plperl[u]? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4787: Hardlink (ln) causes startup failure with bizarre "timezone_abbreviations" error
On Sat, 02 May 2009 14:47:48 GMT, Tom Lane wrote > Mark writes: > > I understand the rationale for relocatable packages. So, > > I guess hardlinks are out. But, barring hardlinks, > > perhaps, in the existence of a symlink, a simple 'readlink' > > function could be done to auto-correct PostgreSQL's > > base-location? Ala: > > That's exactly what it already does, and why it would've worked > if you'd used symlinks not hardlinks. Interesting. Yet, as I reported earlier, whilst a symlink does seem to start the server, pg_ctl takes a long time to do so, and then report: "could not start server" anyway. But it actually *does* get started. So I figured maybe something was not entirely right with the symlink, either. - Mark -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4787: Hardlink (ln) causes startup failure with bizarre "timezone_abbreviations" error
Mark writes: > Interesting. Yet, as I reported earlier, whilst a symlink does seem to start > the server, pg_ctl takes a long time to do so, and then report: "could not > start server" anyway. But it actually *does* get started. So I figured maybe > something was not entirely right with the symlink, either. That sounds like pg_ctl isn't finding the postmaster's socket file ... were you playing games with the location of that, too? pg_ctl is not terribly bright about relocated socket files (in particular, it does not read the postmaster's postgresql.conf, so a nonstandard setting there for unix_socket_directory will confuse it). regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
