"1-Click" installer problems

Nikhil G. Daddikar wrote:

Hi,

I have been trying to install 8.4 on my Vista without success. Earlier
I'd tried to install 8.3 and that failed too.

"Failed" how?

Installer logs?

Details?

I tried installing these
on other Vista machines and they failed too. I searched for google and
enterprisedb forums and there are innumerable requests like mine.

... many of which will be completely unrelated to each other and
describe different issues, but be hard to differentiate because they
lack the detail required to tell what's actually going on.

I *have* seen odd Windows install issues mentioned here, but most of
them turn out to be:

- Installing on unsupported windows like WinXP Embedded
- Pre-existing postgres service accounts with lost passwords
- Damaged installers
- Damaged systems
- Braindead add-on software running on the system, like broken
antivirus or search/indexing tools.

There are also some unexplained issues. People often fail to follow them
up with the level of detail that'd be needed to track down what might be
going on.

I have seen issues get lost or peter out as the back-and-forth of
debugging info doens't achieve anything. Someone dedicated to win32
installer troubleshooting would certainly help - are you volunteering?

Part of the trouble is, frankly, that many people just don't like
working with Windows, particularly with messy things like Windows
installers. EDB is handy because it's hard to get people who'll
volunteer to work on this sort of thing.

Same
with Windows 7. It seems enterprisedb has no clue on what the problem is
and how to fix it. There is not even a guide on how to install
postgresql on Vista or Windows 7. Their 'guide' is only for MacOS. The
"one click" feels like a scam. Search for other threads on their forums
or on google. Their support staff want to be helpful but I think they
just lack the necessary expertise in solving such issues.

They'd need psychic powers to help with the amount of detail you've
provided :-P

I was able to install 8.3 from postgresql.org download site and now I
see 8.4 is no longer supported.

eh? 8.4 no longer supported? That's absolutely not the case. Did you
mean 8.1 ?

I have nothing against enterprisedb but the decision to 'leave out'
windows from postgresql.org download site seems political and will
simply alienate more people from postgresql.

The issue is that many people here don't use Windows and don't have the
expertise required to maintain a win32 installer. The EnterpriseDB folks
do. They were doing it anyway, and it seems pointless to duplicate the
effort producing another installer for the same product, so the old Pg
win32 installer was dropped.

Perhaps it'd be nice to mirror the EDB installer on the main pg site,
but that's a trivial issue.

We advocate pgsql to all
our customers and help them in installation and training at no cost
because we believe that is some way of giving back. With the new
"1-click" we are not sure any more. I strongly recommend that you start
supporting the win32 binary on postgresql.org site again because that
used to work till 8.3 and enterprisedb is failing for a long time.

OK, so let's look into WHY and figure out what's causing that failure.
It works for me on all my win32 systems, and it clearly works for a
significant majority (though I'm sure there are issues) so we need to
find out what makes your setup different and why it's breaking.

--
Craig Ringer

Nikhil G. Daddikar wrote:

I strongly recommend that you start
supporting the win32 binary on postgresql.org site again because that
used to work till 8.3 and enterprisedb is failing for a long time.

Oh: As for the old installer - are you volunteering to maintain it? It
wasn't maintaining its self. Working with Windows installers is an ugly,
unrewarding job where you're constantly battling a new variety of weird
issues due to various breakage and brain-death on the systems the
installer is being used on. People complain "it doesn't work" and then
won't provide enough information to actually find out why - they expect
you to have psychic powers and/or a magic fix-it wand. They angrily
demand an instant fix, as if they'd paid for a product they had some
kind of right to support for.

No wonder nobody likes doing it!

Are you going to take up that workload? Or just demand that somebody
else does it?

--
Craig Ringer

On Thu, 2010-04-01 at 11:30 +0800, Craig Ringer wrote:

Nikhil G. Daddikar wrote:

I strongly recommend that you start
supporting the win32 binary on postgresql.org site again because that
used to work till 8.3 and enterprisedb is failing for a long time.

Oh: As for the old installer - are you volunteering to maintain it? It
wasn't maintaining its self. Working with Windows installers is an ugly,
unrewarding job where you're constantly battling a new variety of weird
issues due to various breakage and brain-death on the systems the
installer is being used on. People complain "it doesn't work" and then
won't provide enough information to actually find out why - they expect
you to have psychic powers and/or a magic fix-it wand. They angrily
demand an instant fix, as if they'd paid for a product they had some
kind of right to support for.

No wonder nobody likes doing it!

Are you going to take up that workload? Or just demand that somebody
else does it?

Although I can understand the frustration, I think a more adequate
response would be:

If EDB was failing for a long time, we would hear a lot more about it.
They host the most downloaded installer .Org has.

Joshua D. Drake

--
Craig Ringer

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.

Joshua D. Drake wrote:

If EDB was failing for a long time, we would hear a lot more about it.
They host the most downloaded installer .Org has.

True. And sorry for grumping.

I've had the misfortune to maintain a win32 installer (in my own time)
before, so this is a bit of a hot button. Sure, it works on every system
I have access to without issues, but because your FarkWare 4000 Super
Privacy Nuker ZX software breaks everything that tries to set file
system permissions, the installer's clearly defective. Argh.

I still shouldn't let it get to me. My apologies to Nikhil.

In any case, while I the EDB installer works extremely well for the
clear majority, like anything it could use improvement, and detailed
constructive feedback on what exactly needs improvement can only be a
good thing. It's the *detailed* bit that needs work right now, though...

( For example, people _do_ get confused by its handling of the postgres
service account, especially during reinstall, and it'd be interesting to
see if there were other approaches taken by other software that avoided
needing to involve the user in working with the postgres service account
password directly. )

--
Craig Ringer

Folks,

Here is my original ticket. It has the screen shot as well as the logs.
Like many other threads on this forum it remains unresolved.

http://forums.enterprisedb.com/posts/list/2235.page

If you want to know the number of people who complain about this
one-click installer, just search that forum. The reason I posted in this
general news group is to make other people aware of the problems that
are being encountered.

And I am not the kind of person who will complain without reasons. I
have spent at least 3 man days trying to install the one-click installer
on multiple Vista machines and every time without success... trying to
find out the problem so that I could post the solution to the forum. I
have been using PG since the last 10 years and we think we do a pretty
good job of it. We have successfully converted people from SQL Server
and Oracle to PG and I think that in itself qualifies as some kind of
"giving back" to PG.

I don't like Windows and I don't like Linux and I don't like Mac. But
they are reality and in my opinion we need to live with it. If PG will
not support Windows Vista or 7, then it should simply say so and I will
keep my mouth shut.... like I did before 8.0. But to move from something
that works i.e PG 8.3 win32 binary to something that doesn't i.e the
1Click installer and then claiming that Windows sucks doesn't go down
well with me. I appreciate the volunteers that have made the database
and the installer till now.

What I would like from EDB is a list of instructions on how to install
it on Vista or Windows 7. I've asked this in the forum but I have not
received any response. Is this too much to ask?

-Nikhil

PS: It is the users that make or break the software not its developers.
So please think twice before asking users to go to hell. Other users
might think it will be their turn to hear this some day.

In about 30 seconds I found the following unanswered threads relating to
installation on Windows Vista. If anybody is interested I can find more.
And I can tell you that a lot of our customers are facing the same
problem with this 1-click gimmicky installer.. something that they never
faced till the 8.3 installer from postgresql.org. And not everybody is
going to post a forum ticket. We've convinced them install 8.3 instead
and that works. But their first experience has been bitter and it
lingers for a long time.

http://forums.enterprisedb.com/posts/list/1815.page

http://forums.enterprisedb.com/posts/list/1132.page

http://forums.enterprisedb.com/posts/list/2175.page

http://forums.enterprisedb.com/posts/list/2033.page

http://forums.enterprisedb.com/posts/list/1186.page

http://forums.enterprisedb.com/posts/list/1605.page

http://forums.enterprisedb.com/posts/list/1578.page

Nikhil G. Daddikar, 01.04.2010 08:04:

In about 30 seconds I found the following unanswered threads relating to
installation on Windows Vista. If anybody is interested I can find more.

The problem with this kind of statistics is that you will only find people who complain, you'll never find people who do not complain because they have no problems. Actually that's true for all internet forums or mailing lists: you'll seldomly find people posting something like "Hey everything works fine, I had no problems".

All the posts seem to share the same root cause: the data directory has been put into "c:\Program Files" but a regular user does not have write permissions on that directory. As the installer is usually run with Administrator rights, the directory can be created but the service (or initdb) runs under a normal user account that cannot write to that directory because.

I do not like the installer's suggestion to put the data directory into c:\Program Files either, I think this should default to %APPDATA% instead of %ProgramFile%. I bet half of the problems would go away if the installer refused to put the data directory into c:\Program Files.

Given the fact that Microsoft finally tries to enforce people not to work as Administrators makes this even more important.

My suggestion is to try to use a different data directory when installing Postgres and make sure that the postgres service account is allowed to read and write that directory.

Personally I switched to using the ZIP packages completely because it is so much easer (unzip, initdb, pg_ctl -register, done)

Thomas

On 01-04-2010 12:39, Thomas Kellerer wrote:

Nikhil G. Daddikar, 01.04.2010 08:04:

In about 30 seconds I found the following unanswered threads relating to
installation on Windows Vista. If anybody is interested I can find more.

The problem with this kind of statistics is that you will only find
people who complain, you'll never find people who do not complain
because they have no problems. Actually that's true for all internet
forums or mailing lists: you'll seldomly find people posting something
like "Hey everything works fine, I had no problems".

I agree... but they are still unanswered. And what else can I do. I am
facing problems on multiple computers, my customers are facing problems
as well. NOBODY till date has managed to install 8.4 on Vista using the
1-click installer and EVERYBODY has managed to install the 8.3 installer
(from postgresql.org) on Vista. DOES THIS COUNT AS A VALID STATISTIC?
And yes, i have tried installing it in C:\Postgresql as well.
Interesting to note that 8.3 installer from postgresql.org installs
perfectly in 'C:\Program Files' even on Vista. No use blaming Windows
all the time. It is the installer that is buggy.

Thomas Kellerer wrote:

All the posts seem to share the same root cause: the data directory has
been put into "c:\Program Files" but a regular user does not have write
permissions on that directory.

Yep. They're also often confused by various steps people have tried
while attempting to get it working, making it very hard to trace what
actually happened initially and why.

I do not like the installer's suggestion to put the data directory into
c:\Program Files either, I think this should default to %APPDATA%

That seems fairly sensible *IF* it checks very carefully to make sure
the postgresql user does not have a roaming profile, ie they're a local
user not a domain user.

If the datadir was put in an account with roaming profiles enabled,
Windows would try to sync the datadir to and from the profile share on
the server at every user login/logout.

This could easily happen if the user overrode the usual account setup
and told the installer to just use their own account. So it needs to be
checked for and detected if %APPDATA% is to be used.

That said, C:\Users\postgresql\AppData\Local\Postgresql is indeed a very
good place to store the database.

instead of %ProgramFile%. I bet half of the problems would go away if
the installer refused to put the data directory into c:\Program Files.

Yep - it's not a clever place to put it.

Given the fact that Microsoft finally tries to enforce people not to
work as Administrators makes this even more important.

They also very strongly discourage storage of variable data in Program
Files. It's like Pg putting it's database in /usr/pgdata .

That said, on my Vista box (which has UAC fully enabled and on which Pg
runs as a normal user account) I had no problems with a default install
with datadir in program files. There's some other factor involved
causing this failure, such as a virus scanner or some funky option.

--
Craig Ringer

Craig Ringer, 01.04.2010 09:24:

I do not like the installer's suggestion to put the data directory into
c:\Program Files either, I think this should default to %APPDATA%

That seems fairly sensible *IF* it checks very carefully to make sure
the postgresql user does not have a roaming profile, ie they're a local
user not a domain user.

I think the installer should simply not "suggest" any directory, but force the user to select one manually (maybe even activley prevent c:\Program Files). I don't know if this is possible (or how hard it would be) but I think a very useful feature for the installer would be to try to check the permissions that the service account has on the chosen data directory.

If the datadir was put in an account with roaming profiles enabled,
Windows would try to sync the datadir to and from the profile share on
the server at every user login/logout.

Ah, didn't think of that one.

such as a virus scanner or some funky option.

True.
In the german Postgres forum there are several posts regarding that topic.

It seems that especially Norton and the Windows built-in Antivirus do not work well with Postgres.
Personally I have no problems with Sophos and Avira

Thomas

I too much preferred the older installer to that oneclick thing, and
regret that we the users aren't at least given a choice.

On Thu, Apr 1, 2010 at 8:57 AM, John R Pierce <pierce@hogranch.com> wrote:

I too much preferred the older installer to that oneclick thing, and regret
that we the users aren't at least given a choice.

You're free to maintain the old one if you like. Be warned though - it
had a much higher failure rate than the one-click installer (which
based on the ratio of downloads to bug reports, is down to something
like 45000:1 at this point, or a 99.997% success rate).

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Thu, Apr 1, 2010 at 6:47 AM, Nikhil G. Daddikar <ngd@celoxis.com> wrote:

Folks,

Here is my original ticket. It has the screen shot  as well as the logs.
Like many other threads on this forum it remains unresolved.

http://forums.enterprisedb.com/posts/list/2235.page

What I would like from EDB is a list of instructions on how to install it on
Vista or Windows 7. I've asked this in the forum but I have not received any
response. Is this too much to ask?

Maybe I'm missing something, but I see 5 responses from 2 of our
engineers over the last 2 days on that thread, all asking valid
questions and trying to figure out why this is failing for you, when
it does not for the vast majority of other users. I appreciate that
you do not want to do a manual installation, but for us to understand
why it is failing in your particular case, we need to do some
exploration.

Sachin told you how to install in a nutshell, but I guess you missed
that so here are the detail walkthrough instructions:
http://www.enterprisedb.com/learning/pginst_guide.do

I don't think that's bad for *free* support.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Thu, Apr 1, 2010 at 8:24 AM, Craig Ringer
<craig@postnewspapers.com.au> wrote:

Thomas Kellerer wrote:

All the posts seem to share the same root cause: the data directory has
been put into "c:\Program Files" but a regular user does not have write
permissions on that directory.

Yep. They're also often confused by various steps people have tried
while attempting to get it working, making it very hard to trace what
actually happened initially and why.

Actually, most errors used to happen when the user wasn't using that
directory. We finally tracked down what we believe to be the primary
outstanding cause of initdb failures and fixed it for 8.4.3/8.3.10 btw
- it took a brainstorming session and a great deal of thought from
Magnus and I, as well as the help of a user from a US .gov site with
very tight security procedures to track it down.

I do not like the installer's suggestion to put the data directory into
c:\Program Files either, I think this should default to %APPDATA%

The reasons why we do that have been discussed here before - check the archives.

As a point of reference - wanna guess where Microsoft SQL Server puts
it's data by default?

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Maybe I'm missing something, but I see 5 responses from 2 of our
engineers over the last 2 days on that thread, all asking valid
questions and trying to figure out why this is failing for you, when
it does not for the vast majority of other users. I appreciate that
you do not want to do a manual installation, but for us to understand
why it is failing in your particular case, we need to do some
exploration.

It is not the count that matters. It is the quality. Even after giving
logs, your folks are unable to figure out the problem. I am facing the
same problem that was faced by a lot of users on the forum and not one
was resolved successfully. Otherwise I would've moved ahead on my own. I
am interested in fixing the installer. I am not interested in manual
steps to get it working on my PC because there are a hundred other PCs
that I have to worry about and a fix in the installer would be right
step ahead. But someone has to admit that there is a problem in the
installer. All arguments in this thread are junk because 8.3 installer
for win32 from postgresql.org WORKS using the same conditions on
Vista/2003/7 everywhere. It is nothing to do with APPDATA or any such
thing. Something that worked was broken, it's that simple. And nobody
wants to know what was.

Sachin told you how to install in a nutshell, but I guess you missed
that so here are the detail walkthrough instructions:
http://www.enterprisedb.com/learning/pginst_guide.do

I don't think that's bad for *free* support.

If you mean the number of responses, yes it's great.

The reason I posted this in the general newsgroup is because I thought
others would like to know what's going on. But I think this is a
newsgroup with a bunch of inflated egos who want to do everything else
rather than address the problem. A typical open-source group.
Evangelizing PGSQL was a mistake.

Thanks for all your help and good luck to everyone!
-n.

If you really want to help and make the installer a better experience, i
asked for helping me out debug the issue
"Run the initcluster.vbs and let us know at what line number you are
getting the 'Object Required' error message".

But all you replied was : - " I need step by step procedure to install
it on Vista or Windows 7, I dont want bits and pieces stuff"..

And then you expect us to help out. If you really care then help out,
there is just no point saying, that was working and that's not again and
again.

If you mean the number of responses, yes it's great.

The reason I posted this in the general newsgroup is because I thought
others would like to know what's going on. But I think this is a
newsgroup with a bunch of inflated egos who want to do everything else
rather than address the problem. A typical open-source group.
Evangelizing PGSQL was a mistake.

Thanks for all your help and good luck to everyone!
-n.

--
Regards,
Sachin Srivastava
EnterpriseDB <http://www.enterprisedb.com&gt;, the Enterprise Postgres
<http://www.enterprisedb.com&gt; company.

2010/4/1 Craig Ringer <craig@postnewspapers.com.au>:

instead of %ProgramFile%. I bet half of the problems would go away if
the installer refused to put the data directory into c:\Program Files.

Yep - it's not a clever place to put it.

IIRC, that was modeled on where Microsofts own SQL Server put it's
data files by default. Does anybody know if that has changed recently?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Thu, Apr 1, 2010 at 10:35 AM, Nikhil G. Daddikar <ngd@celoxis.com> wrote:

It is not the count that matters. It is the quality. Even after giving logs,
your folks are unable to figure out the problem.

No, because clearly it is not a simple issue.

I am facing the same
problem that was faced by a lot of users on the forum and not one was
resolved successfully.

Actually, not you weren't. Of the cases you quoted, some were from
completely different pieces of software, one was a request for
information which a sales guy followed up, and the remaining ones
included some people for whom a fix was found, some for whom one
wasn't, and some who didn't provide the required information to
diagnose the problem.

Also, there are a number of different issues that can cause an initdb
failure. We've worked hard to work around as many of those as possible
in the installer, but some are just damn hard to track down - and
pretty much impossible if people won't help us when they see a
failure. Just because you see the same outward symptoms, it does not
mean that you have the same underlying problem.

Otherwise I would've moved ahead on my own. I am
interested in fixing the installer. I am not interested in manual steps to
get it working on my PC because there are a hundred other PCs that I have to
worry about and a fix in the installer would be right step ahead. But
someone has to admit that there is a problem in the installer.

Noone has said there isn't some situation that the installer cannot
properly handle - I'm sure there are more than a few, knowing how
widely installations of Windows can vary from machine to machine, or
domain to domain.

We want to fix any issues in the installer - but we cannot simply
guess what's going wrong. That can take time and effort to understand.

The reason I posted this in the general newsgroup is because I thought
others would like to know what's going on. But I think this is a newsgroup
with a bunch of inflated egos who want to do everything else rather than
address the problem. A typical open-source group. Evangelizing PGSQL was a
mistake.

You've had a people try to help you on the forum.

You've had people here try to suggest how you might help us to help you.

You've even had someone someone telephone your office to try to help
(again, for free), who you refused to talk to.

Unless you are prepared to help us understand exactly what is unique
about your systems so we can figure out what is going wrong, then we
cannot help you.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Thu, Apr 1, 2010 at 10:50 AM, Magnus Hagander <magnus@hagander.net> wrote:

2010/4/1 Craig Ringer <craig@postnewspapers.com.au>:

instead of %ProgramFile%. I bet half of the problems would go away if
the installer refused to put the data directory into c:\Program Files.

Yep - it's not a clever place to put it.

IIRC, that was modeled on where Microsofts own SQL Server put it's
data files by default. Does anybody know if that has changed recently?

It hasn't. I checked 2008 this morning.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com