Recommended Posts

Posted

Hawkhost,

I am intending to transfer my WHM/cPanel reseller account to a new host before the end of July, and am seriously considering Hawkhost's "Advanced Reseller" package as one of the options. I have been speaking with Cody via Live Chat, and he has answered most of my questions, but there is one issue that I am still not completely satisfied with.

Although Cody assured me that if I transferred to HH (I would prefer the Washington DC, as I am based in the UK), PHP support for PDO+pgsql could be enabled on request. This is such a deal-breaker for me, and I have had such problems with my current host, that I really would like to see this with my own eyes.

Would it be possible for you to send me a link to a live phpinfo() output on one of your Washington servers, showing that PHP PDO Support for PostgreSQL has been enabled?

If you would prefer to send it privately, then this would, of course, be acceptable.

Thank you in advance

Hal

Posted

We run PDO on all our servers by default and as far as the pdo_pgsql it's not installed by default but we could easily install it as the PDO support is already there and pdo_pgsql is just a PECL extension.

As for phpinfo outputs we do not provide them as there is no guarantee that every server is identical due to some PDO extensions being different. So in your case once you signed up and were assigned a server you could check the server you're on and if it's not there make a ticket and we can add it.

Posted

Tony

OK, I appreciate your point of view regarding phpinfo being different on each server (although I believe there would be value in making the PHP config consistent across all servers, from a management and support perspective), but it really is important for me to have the assurance of seeing that you have already successfully installed it, even if it's on a different server.

Please would you send me a link to phpinfo() hosted on *any* server with PDO+pgsql enabled?

Thank you

Hal

Posted

Not a single server has pdo_pgsql installed on it currently. I know it'll install fine since we have pdo_mysql and pdo_sqlite are already loaded on them and both are PECL modules which makes them easy to install.

Posted

Tony

As does my current host, but they have not been able to install and enable pdo+pgsql support.

If you are able to show me that Hawkhost can provide this, by proving it in a phpinfo() output, then you will have my custom.

I hope you can appreciate how crucial this issue is to me.

Thank you

Hal

Posted

Thank you for your last post, Tony.

So that there is no ambiguity, would you confirm that the phpinfo output in your previous attachment was produced by a live server *running cPanel*? If so, you have achieved what my current host could not achieve in 8 long months! cPanel staff have also said that the installation of PHP PDO*pgsql support is not straightforward (see http://forums.cpanel.net/f4/error-create-postgres-databases-114029.html#post512157. I am sure you can appreciate why I am a little surprised by how easy you have found it.

Cody has assured me that Hawkhost always runs the latest version of PostgreSQL, and even 3 months ago, when I spoke to him last, you had already moved to PostgreSQL 8.3. Despite this, your attachment shows that the installed version is only 8.1. Could you explain this?

I would feel more comfortable seeing the phpinfo output directly. Once you have addressed the above points, would you please give me access to it temporarily?

Thank you again

Hal

Posted
Thank you for your last post, Tony.

So that there is no ambiguity, would you confirm that the phpinfo output in your previous attachment was produced by a live server *running cPanel*? If so, you have achieved what my current host could not achieve in 8 long months! cPanel staff have also said that the installation of PHP PDO*pgsql support is not straightforward (see http://forums.cpanel.net/f4/error-create-postgres-databases-114029.html#post512157. I am sure you can appreciate why I am a little surprised by how easy you have found it.

You can compile any PDO module through PECL which makes a .so which is then just added to the php.ini file.

Cody has assured me that Hawkhost always runs the latest version of PostgreSQL, and even 3 months ago, when I spoke to him last, you had already moved to PostgreSQL 8.3. Despite this, your attachment shows that the installed version is only 8.1. Could you explain this?

We run the latest available in our distribution as there have been issues with 8.3, our cPanel setup and our 64bit systems. So we're running the CentOS distribution back ported version as it actually works properly. We will not be upgrading any machines to 8.3. The fact is PostgreSQL has a very poor upgrade system last time I checked. The solution is to just dump all DB's then import them in again which is just insane to do in a hosting environment. So that's why cPanel support is poor at best (you install it then it maybe works unlike MySQL which they maintain the versions). So we stick with CentOS version which will work as far as upgrades for security issues only.

So Cody is mistaken we no longer run 8.3 after all our systems became 64bit.

I would feel more comfortable seeing the phpinfo output directly. Once you have addressed the above points, would you please give me access to it temporarily?

Thank you again

Hal

It's not information we want to give to someone who is not a customer of ours. If anyone trying to sell you on our hosting they should not have done that. You asked if it was there I provided an image of it. Our PHP is compiled with everything that is compatible out of the box including PDO, MySQLi ect. ect. Past that we load the odd PECL module when users request them and there is no risk of causing issues.

Compile line:


'./configure' '--enable-bcmath' '--enable-calendar' '--enable-dbase' '--enable-exif' '--enable-ftp' '--enable-gd-native-ttf' '--enable-libxml' '--enable-magic-quotes' '--enable-mbstring' '--enable-pdo=shared' '--enable-soap' '--enable-sockets' '--enable-wddx' '--enable-zip' '--prefix=/usr/local' '--with-bz2' '--with-curl=/opt/curlssl/' '--with-curlwrappers' '--with-freetype-dir=/usr' '--with-gd' '--with-gettext' '--with-imap=/opt/php_with_imap_client/' '--with-imap-ssl=/usr' '--with-jpeg-dir=/usr' '--with-kerberos' '--with-libdir=lib64' '--with-libexpat-dir=/usr' '--with-libxml-dir=/opt/xml2' '--with-libxml-dir=/opt/xml2/' '--with-mcrypt=/opt/libmcrypt/' '--with-mhash=/opt/mhash/' '--with-mime-magic' '--with-mysql=/usr' '--with-mysql-sock=/var/lib/mysql/mysql.sock' '--with-mysqli=/usr/bin/mysql_config' '--with-openssl=/usr' '--with-openssl-dir=/usr' '--with-pdo-mysql=shared' '--with-pdo-sqlite=shared' '--with-pgsql=/usr' '--with-pic' '--with-png-dir=/usr' '--with-pspell' '--with-sqlite=shared' '--with-tidy=/opt/tidy/' '--with-ttf' '--with-xmlrpc' '--with-xpm-dir=/usr' '--with-xsl=/opt/xslt/' '--with-zlib' '--with-zlib-dir=/usr' '--with-litespeed'
[/CODE]

Posted
We run the latest available in our distribution as there have been issues with 8.3, our cPanel setup and our 64bit systems. So we're running the CentOS distribution back ported version as it actually works properly. We will not be upgrading any machines to 8.3.

This is disappointing, as PostgreSQL 8.3 has many improvements over 8.1, not least performance.

If anyone trying to sell you on our hosting they should not have done that.

Sorry, but I do not understand what you mean by this. Would you explain?

Thanks

Hal

Posted
This is disappointing, as PostgreSQL 8.3 has many improvements over 8.1, not least performance.

Sorry, but I do not understand what you mean by this. Would you explain?

Thanks

Hal

Basically giving you links to phpinfo files there are reasons a lot of people disable the ability to generate them at all (we don't do that).

As for PostgreSQL the problem with them as I stated is they provide no way to even upgrade. You get a version you're stuck with it. You want to upgrade then you dump all your data and import it again. Not exactly ideal for a shared hosting environment. Data has to be inserted in a certain order there is no guarantee that happens again when going back. Also the fact that you'd have down time associated with it. This explains why very few have latest versions ever. Right now the latest version is actually 8.4 but I doubt anyone is running it.

We'd have numerous issues getting 8.3 to run in our 64bit systems (ran fine in 32bit). So we choose to use the CentOS distribution version which is 8.1 with all fixes backported to it. We choose to use a version that works over nothing at all.

So we can maintain most things MySQL, PHP ect. but PostgreSQL is a nightmare to do unfortunately. Someone wants 8.4 we'd have to say to an entire server we're going to dump all data currently then import again and hopefully it goes back in order! Everything else you upgrade and you might worry about incompatibilties only not the fact that you may have broke everything switching versions.

For reference their guide to upgrading between versions: http://www.postgresql.org/docs/8.4/static/install-upgrading.html

MySQL for example says you may have issues make a backup. Not you cannot even attempt to upgrade without re-importing data.

Posted (edited)

Tony

As far as I have always heard in the Postgres community, everyone regards version 8.3 as very stable and unproblematic. I must admit that I have only run the 32bit version myself, but someone I know has 15 clusters running on 64bit machines with issue. I would be grateful if you could explain the main issue and symptom, so that I may find out whether the postgres devs are aware of it?

Having said that, it is depressing to discover that even Centos 5.3 is still on Postgres 8.1, despite the latest version being 8.4. This certainly doesn't make a hosting company's job, like yours, any easier!

Data has to be inserted in a certain order there is no guarantee that happens again when going back.

I believe that you can use the -o option when running pg_dumpall, which preserves OIDs (such as when using them as foreign keys).

As for PostgreSQL the problem with them as I stated is they provide no way to even upgrade. You get a version you're stuck with it. You want to upgrade then you dump all your data and import it again. Not exactly ideal for a shared hosting environment. Data has to be inserted in a certain order there is no guarantee that happens again when going back.

Someone wants 8.4 we'd have to say to an entire server we're going to dump all data currently then import again and hopefully it goes back in order!

I can appreciate your point, but one solution for new servers could be to run 8.1 on its standard port, and install an instance of 8.3 (or 8.4) concurrently on a different port. This would allow users to migrate in their own time, and at their own discretion. Although this would mean running two processes, the users using 8.3 would use the server's resources much more efficiently, which would help to offset any drawbacks.

Hal

Edited by hal
Posted
Tony

As far as I have always heard in the Postgres community, everyone regards version 8.3 as very stable and unproblematic. I must admit that I have only run the 32bit version myself, but someone I know has 15 clusters running on 64bit machines with issue. I would be grateful if you could explain the main issue and symptom, so that I may find out whether the postgres devs are aware of it?

Having said that, it is depressing to discover that even Centos 5.3 is still on Postgres 8.1, despite the latest version being 8.4. This certainly doesn't make a hosting company's job, like yours, any easier!

It was probably a combination of cPanel and the 64bit system. Basically we could install it but never integrate it properly it just would not work. Unable to setup configurations properly and such. Just not something interested in exploring at this point.

I believe that you can use the -o option when running pg_dumpall, which preserves OIDs (such as when using them as foreign keys).

Last time I did one there were issues with the triggers and stored procedures. Was an old old version though

I can appreciate your point, but one solution for new servers could be to run 8.1 on its standard port, and install an instance of 8.3 (or 8.4) concurrently on a different port. This would allow users to migrate in their own time, and at their own discretion. Although this would mean running two processes, the users using 8.3 would use the server's resources much more efficiently, which would help to offset any drawbacks.

Hal

Except all the cPanel integration breaks.

So we're sticking with what we have not going to go outside of it at this point.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...