Thread: How to run PostgreSQL?

[root@callisto init.d]# chmod 755 /etc/init.d/postgres

[root@callisto init.d]# gedit /etc/init.d/postgres

[root@callisto init.d]# ln -s /etc/init.d/postgres /etc/rc2.d/S85postgres

[root@callisto init.d]# ln -s /etc/init.d/postgres /etc/rc3.d/S85postgres

[root@callisto init.d]# /etc/init.d/postgres start

Starting PostgreSQL: ok
I wonder what is the best way to get PostgreSQL working? Any help in this regard will be highly appreciated..

Regards

-Jan Muhammad

On Thu, May 07, 2009 at 04:38:59AM -0700, Jan Muhammad wrote:
> Hi,
>
> I have just downloaded, installed/configured postgresql version 8.2.11 on Fedora Core 6. While reading through the
installationmanual have setup most of its parts; now while trying to run datebase server with the command:??  
> $ postmaster -D /usr/local/pgsql/data


did you do initdb?
http://www.postgresql.org/docs/8.2/interactive/creating-cluster.html

On May 7, 2009, at 7:26 AM, Ray Stell wrote:

> On Thu, May 07, 2009 at 04:38:59AM -0700, Jan Muhammad wrote:
>> Hi,
>>
>> I have just downloaded, installed/configured postgresql version
>> 8.2.11 on Fedora Core 6. While reading through the installation
>> manual have setup most of its parts; now while trying to run
>> datebase server with the command:??
>> $ postmaster -D /usr/local/pgsql/data
>


Doesn't it come with the package manager and can't you not run it from
init.d?
If not, read the installation tutorial that comes with the source. But
I hope you don't compile 8.2.11 now from source, right?

Ries

On Thu, May 07, 2009 at 07:49:56AM -0500, Ries van Twisk wrote:
> I hope you don't compile 8.2.11 now from source, right?

I never understood this attitude.  Do this commands really
make for a daunting adventure.  Why the trepidation?
  http://www.postgresql.org/docs/8.2/interactive/install-short.html

Zitat von Jan Muhammad <janmuhd@yahoo.com>:

> Hi,
>
> I have just downloaded, installed/configured postgresql version
> 8.2.11 on Fedora Core 6. While reading through the installation
> manual have setup most of its parts; now while trying to run
> datebase server with the command:  
> $ postmaster -D /usr/local/pgsql/data
>
> I get the following error:
>
> "FATAL:  data directory "/usr/local/pgsql/data" has group or world access
> DETAIL:  Permissions should be u=rwx (0700)."

Simply fix this by do a chmod -R 700 /usr/local/pgsql/data

> Although I'm running this command from user 'postgres'; who has the
> ownership of /pgsql/data directories as well.
>
> Secondly, when I try to check that postgresql service is running or
> not; with the command: # service postgrsql status
> postgrsql: unrecognized service

Typo? Maybe should be "service postgresql status"

Regards

Andreas

Hi Jan

> initdb: directory "/usr/local/pgsql/data" exists but is not empty
> If you want to create a new database system, either remove or empty
> the directory "/usr/local/pgsql/data" or run initdb
> with an argument other than "/usr/local/pgsql/data"
> --------------------------------------------------------------------------
>
> Wonder what step I have missed?
>

Exactly what it says.  The directory "/usr/local/pgsql/data" exists and
has some data in it.  In order to get initdb to use this directory, you
need to either delete it, rename it or give initdb a different path
other than "/usr/local/pgsql/data".

If you have run initdb before in this directory (and it succeeded) you
don't need to do it again.  It's possible the package manager/RPM may
have run this for you when it installed PgSQL.

If you're setting up a new PostgreSQL server, why are you using 8.2.11?
For starters, the 8.3 branch is the most recent, with 8.3.7 being the
current release of that branch, but there's also a more recent 8.2
release than the one you've just installed, 8.2.13.

Ray, I agee with your comment; I always prefer source compilation over
package management.

Regards,
Andy

Jan Muhammad <janmuhd@yahoo.com> writes:
> It wasn't�installed with package manager; I�downloaded and
> followed the PDF manual from the link (
> http://www.postgresql.org/docs/manuals/). But now while I installed it
> from source; if try to check it with (#rpm -q postgresql ), I get
> "Package postgresql is not installed".

Well, yeah, because you didn't install it from an RPM, so none of the
RPM management tools know anything about it.

            regards, tom lane

On Thu, 2009-05-07 at 09:01 -0400, Ray Stell wrote:
> On Thu, May 07, 2009 at 07:49:56AM -0500, Ries van Twisk wrote:
> > I hope you don't compile 8.2.11 now from source, right?
>
> I never understood this attitude.

Because "users" shouldn't compile. The commands aren't relevant. If
possible you should *always* run from your package manager.

>  Do this commands really
> make for a daunting adventure.  Why the trepidation?
>   http://www.postgresql.org/docs/8.2/interactive/install-short.html
>

 * Why should I install 40 different packages to install PostgreSQL?
 * Why should I have to edit /etc/profile or .bashrc or /etc/profile.d?
 * Why should I have yet another channel to watch to see if there is a
critical update?
 * Why should I have to know where my postgresql is? (speaking from a
user perspective not a DBA)
 * Why should I have to configure a custom init.d script so my
PostgreSQL will start?

I can go on, and on, and on...

Sincerely,

Joshua D. Drake




--
PostgreSQL - XMPP: jdrake@jabber.postgresql.org
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997

you have a data directory alredy?

try to use another directory

$ mkdir /usr/local/pgsql/data2
$ chown postgres:postgres /usr/local/pgsql/data2
$ initdb -D /usr/local/pgsql/data2


--- On Thu, 5/7/09, Jan Muhammad <janmuhd@yahoo.com> wrote:

> From: Jan Muhammad <janmuhd@yahoo.com>
> Subject: Re: [ADMIN] How to run PostgreSQL?
> To: "Ray Stell" <stellr@cns.vt.edu>
> Cc: pgsql-admin@postgresql.org
> Date: Thursday, May 7, 2009, 3:19 PM
> Hi,
>
> Yes I had done that step prior to writing on group. But now
> if I try to re-run I get the following error:
>
> [postgres@callisto local]$ initdb -D /usr/local/pgsql/data
>
> The files belonging to this database system will be owned
> by user "postgres".
> This user must also own the server process.
>
> The database cluster will be initialized with locale
> en_US.UTF-8.
> The default database encoding has accordingly been set to
> UTF8.
>
> initdb: directory "/usr/local/pgsql/data" exists
> but is not empty
> If you want to create a new database system, either remove
> or empty
> the directory "/usr/local/pgsql/data" or run
> initdb
> with an argument other than
> "/usr/local/pgsql/data"
> --------------------------------------------------------------------------
>
> Wonder what step I have missed?
>
> -Jan Muhammad
>
>
> --- On Thu, 5/7/09, Ray Stell <stellr@cns.vt.edu>
> wrote:
>
> From: Ray Stell <stellr@cns.vt.edu>
> Subject: Re: [ADMIN] How to run PostgreSQL?
> To: "Jan Muhammad" <janmuhd@yahoo.com>
> Cc: pgsql-admin@postgresql.org
> Date: Thursday, May 7, 2009, 5:26 PM
>
>
> -----Inline Attachment Follows-----
>
> On Thu, May 07, 2009 at 04:38:59AM -0700, Jan Muhammad
> wrote:
> > Hi,
> >
> > I have just downloaded, installed/configured
> postgresql version 8.2.11 on Fedora Core 6. While reading
> through the installation manual have setup most of its
> parts; now while trying to run datebase server with the
> command:??
> > $ postmaster -D /usr/local/pgsql/data
>
>
> did you do initdb?
> http://www.postgresql.org/docs/8.2/interactive/creating-cluster.html

On Thu, May 07, 2009 at 09:58:04AM -0700, Joshua D. Drake wrote:
> Because "users" shouldn't compile. The commands aren't relevant. If
> possible you should *always* run from your package manager.

don't you need root to do package management?  Maybe that is just
Red Hat like.  Hmm, not on OS X.

>  * Why
...
>  * Why should I have to configure a custom init.d script so my
> PostgreSQL will start?

to gain control over the system issue.  From my perspective pg has always
been at the enterprise layer, so sysadmin/dba are on the hook.  Those guys
don't like to hand over control to anyone, and therefore the commands
are relevant.  Isn't that  why they are in the manual.

I see where you are coming from, standardization in order to lower
maintenance costs.  Maybe the install guide needs a branch per your
approach?  The fact that this thread exists might be a testimony to
that.

On Fri, 2009-05-08 at 10:19 -0400, Ray Stell wrote:
> On Thu, May 07, 2009 at 09:58:04AM -0700, Joshua D. Drake wrote:
> > Because "users" shouldn't compile. The commands aren't relevant. If
> > possible you should *always* run from your package manager.
>
> don't you need root to do package management?  Maybe that is just
> Red Hat like.  Hmm, not on OS X.

You need at least sudo yes but then again, if you don't have that level
of authority on the machine, you shouldn't be installing the software in
the first place.

>
> >  * Why
> ...
> >  * Why should I have to configure a custom init.d script so my
> > PostgreSQL will start?
>
> to gain control over the system issue.  From my perspective pg has always
> been at the enterprise layer,

This surprises me a bit. In my experience Enterprises don't compile from
source and those that do, push it into a package so they can manage it.

Wait... there is one place in the "enterprise" where I could see this
being the case. Places that are running legacy systems like AIX or HPUX
that don't necessarily even have a proper package management system.

>  so sysadmin/dba are on the hook.  Those guys
> don't like to hand over control to anyone, and therefore the commands
> are relevant.

Wow, I really wouldn't want to work where ever it is you work :)


> Isn't that  why they are in the manual.

No. They are in the manual because we don't want to bloat the manual out
with how to install postgresql on 12 different platforms.

> I see where you are coming from, standardization in order to lower
> maintenance costs.  Maybe the install guide needs a branch per your
> approach?  The fact that this thread exists might be a testimony to
> that.

Actually I think we need a place on the wiki for it because it is fairly
dynamic.

Joshua D. Drake


>
--
PostgreSQL - XMPP: jdrake@jabber.postgresql.org
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997

jd@commandprompt.com ("Joshua D. Drake") writes:
>> >  * Why should I have to configure a custom init.d script so my
>> > PostgreSQL will start?
>>
>> to gain control over the system issue.  From my perspective pg has always
>> been at the enterprise layer,
>
> This surprises me a bit. In my experience Enterprises don't compile from
> source and those that do, push it into a package so they can manage it.
>
> Wait... there is one place in the "enterprise" where I could see this
> being the case. Places that are running legacy systems like AIX or HPUX
> that don't necessarily even have a proper package management system.

There are two other scenarios that I have seen that have led us to
generally compile from sources, both with common features:

  a) Slony-I expects to be built alongside the database.

     In principle, the relevant compiled components *could* be added
     in via PGXS, but nobody has had the time to set that up; it
     hasn't seemed that valuable to do.

  b) We've got some internal data types that expect to be built in
     contrib/

     Again, we could presumably use PGXS to evade this...  Mumble...

It would be *conceivable* to build RPMs or something, but that seems
more trouble than it's worth for, erm, AIX :-).
--
select 'cbbrowne' || '@' || 'cbbrowne.com';
http://linuxdatabases.info/info/multiplexor.html
"Bother," said Pooh as he struggled with sendmail.cf.
"It never does quite what I want."
"I wish Christopher Robin were here.".

On Fri, 8 May 2009 10:19:29 -0400
Ray Stell <stellr@cns.vt.edu> wrote:

> don't you need root to do package management?  Maybe that is just
> Red Hat like.  Hmm, not on OS X.

Well you expect that every single header that postgresql needs to be
built from source is already on the system? If not you need access to
package management anyway. And if you don't have super user
privileges, you shouldn't be doing the installation of a database in
the first place at all.


> to gain control over the system issue.

Compiler shouldn't be installed on a production system in the first
place.

By installing software from source you loose control. For example, take
a look at eaccelerator for PHP on debian. There is no package, so after
every critical update in PHP, I need to:

# aptitude install gcc php-dev
# cd ~/php-eaccel
# make clean
# phpize
# make
# make install
# aptitude purge gcc php-dev (along with dozen of dependencies)

And now, that is pretty straightforward, because if I don't do that,
Apache won't start because PHP won't be able to load eaccelerator.so.
And compilation time is around 2 or 3 seconds :) But if the software
was a database engine like PostgreSQL, wich depends on dozens of libs,
I just don't want to get in that situation. That means more downtime
after upgrade of every system component PostgreSQL depends on. And you
call that enterprise?

Not to mention if software is from source, it is in most cases
neglected in security aspect. Nobody monitors security issues for every
app, it is much easier to lean on the distribution vendor.

And what about system hygiene? When stuff is installed from packages,
you at least know where does a file come from, has it been modified,
and from when it is there.

And I could go on forever accounting bad things on this subject. Look
at what happens to Windows, because it doesn't have proper package
management... Look and learn.


> From my perspective pg has always been at the enterprise layer, so
> sysadmin/dba are on the hook.  Those guys don't like to hand over
> control to anyone, and therefore the commands are relevant.  Isn't
> that  why they are in the manual.

I'm afraid you're mixing a lot of stuff. If you use packages, you are
not off the hook. You don't hand over anything to anyone. You think
that ./configure && make && make install run by you produce better
output than same set of commands run by package maintainer, just
because _you_ have run it?! I frankly don't understand logic behind any
of these points.

And commands are in manual because there are dozens of distros out
there (and some of them just lack the pg packages). Also someone
has to show to package maintainers how to actually build the damn thing?


> I see where you are coming from, standardization in order to lower
> maintenance costs.  Maybe the install guide needs a branch per your
> approach?  The fact that this thread exists might be a testimony to
> that.

You are (again) going in totaly wrong direction. Packages have nothing
to do with standardization or maintenance costs. System admin won't get
more $$$ if he compiles stuff from source and not just apt-gets them.
Maintenance has nothing to do with INSTALLATION OF SOFTWARE. It's easy
to install, everyone can build the damn thing. Problem is tunning,
troubleshooting and stuff like that. And packages help even in that,
because you are not alone with your obscure compiled application and
some strange error for which you can't conclude is it because of your
environment, or is it pgsql binary problem. If package has problem,
chances are very high someone noticed it before you and reported it,
and you got fixed revision.


After reading all of your comments, I must give you a friendly advice.
Re-learn logic behind system administration, because you are bloody
wrong in most of cases presented here... And these are fundamentals on
top of which you build on :(




--
|    Jakov Sosic    |    ICQ: 28410271    |   PGP: 0x965CAE2D   |
=================================================================
| start fighting cancer -> http://www.worldcommunitygrid.org/   |