Re: [HACKERS] [Pgsqlrpms-hackers] Safer auto-initdb for RPM init

2006-08-26 Thread Alvaro Herrera
Andrew Dunstan wrote:
> 
> Alvaro Herrera wrote:

> >This is trivial to do --- just add a /etc//postgresql file
> >that contains a line like
> >
> >AUTO_INITDB=0
> >
> >to turn the auto-initdb'ing feature of the init script off.  If the file
> >is not present or AUTO_INITDB is not defined to zero in that file, then
> >the code behaves as today.  I don't recall what the configuration
> >directory is called in Redhat systems, but there is one in there (in
> >Debian it's /etc/default).  
> 
> I don't see anything like this in my FC5 box's init script.

Obviously I was thinking in something else when I wrote that, because
what I wanted to say but failed, was that I suggested that the RPM
hackers could *add* such a thing to the initscript -- not that it
already existed :-)

Hum, I must be still thinking in something else because I'm failing to
write the above paragraph in a coherent manner (rewrote it twice
already).  I hope you understand it anyway :-)

> Oh, and the place you put stuff like that on RH/FC systems is /etc/sysconfig

Yeah, that one :-)

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] [Pgsqlrpms-hackers] Safer auto-initdb for RPM init

2006-08-26 Thread Andrew Dunstan



Alvaro Herrera wrote:

Jim C. Nasby wrote:
  

On Fri, Aug 25, 2006 at 07:21:50AM -0700, Joe Conway wrote:

We also decided to turn off the init script execution entirely. The DBAs 
were more comfortable with a manual database startup for a production 
machine anyway (this is the way they typically handle Oracle databases 
also). They get paged if the server ever goes down unplanned, and in 
that event they like to check things out before bringing the db back up. 
For planned outages, database startup is simply part of the plan.
  

I'd *really* like to have an official way to just disable the initdb
code entirely.



This is trivial to do --- just add a /etc//postgresql file
that contains a line like

AUTO_INITDB=0

to turn the auto-initdb'ing feature of the init script off.  If the file
is not present or AUTO_INITDB is not defined to zero in that file, then
the code behaves as today.  I don't recall what the configuration
directory is called in Redhat systems, but there is one in there (in
Debian it's /etc/default).  

  


I don't see anything like this in my FC5 box's init script.

Oh, and the place you put stuff like that on RH/FC systems is /etc/sysconfig

cheers

andrew

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] [Pgsqlrpms-hackers] Safer auto-initdb for RPM init script

2006-08-26 Thread Alvaro Herrera
Jim C. Nasby wrote:
> On Fri, Aug 25, 2006 at 07:21:50AM -0700, Joe Conway wrote:
> > We also decided to turn off the init script execution entirely. The DBAs 
> > were more comfortable with a manual database startup for a production 
> > machine anyway (this is the way they typically handle Oracle databases 
> > also). They get paged if the server ever goes down unplanned, and in 
> > that event they like to check things out before bringing the db back up. 
> > For planned outages, database startup is simply part of the plan.
> 
> I'd *really* like to have an official way to just disable the initdb
> code entirely.

This is trivial to do --- just add a /etc//postgresql file
that contains a line like

AUTO_INITDB=0

to turn the auto-initdb'ing feature of the init script off.  If the file
is not present or AUTO_INITDB is not defined to zero in that file, then
the code behaves as today.  I don't recall what the configuration
directory is called in Redhat systems, but there is one in there (in
Debian it's /etc/default).  

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] [Pgsqlrpms-hackers] Safer auto-initdb for RPM init

2006-08-26 Thread Matthew T. O'Connor

Joshua D. Drake wrote:

Matthew T. O'Connor wrote:

Jim C. Nasby wrote:

As Tom mentioned, it's for newbie-friendliness. While I can understand
that, I think it needs to be easy to shut that off.


I understand that, but it seems the whole problem of people 
overwriting there data dir is because we initdb from the start 
script.  If we installed the datadir during the RPM install, it would 
still be newbie friendly and would removed initdb from start script 
solving that problem.


 initdb will not overwrite an existing installation. 


Poorly chosen words.  I meant, the problem where the start script will 
create a new data dir when it doesn't see that one exists even though 
one actually does exist it's just not available at the moment.  Either 
way, if the start scripts never created a data dir, then there is no 
problem.


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] [Pgsqlrpms-hackers] Safer auto-initdb for RPM init

2006-08-26 Thread Joshua D. Drake

Matthew T. O'Connor wrote:

Jim C. Nasby wrote:

On Sat, Aug 26, 2006 at 01:32:17PM -0700, Joshua D. Drake wrote:
I am not exactly sure why we initdb at all. IMHO it would be better 
if the start script just checked if there was a cluster. If not, it 
wouldn't start, it would error with: You do not have a cluster, 
please read man page on initdb.


As Tom mentioned, it's for newbie-friendliness. While I can understand
that, I think it needs to be easy to shut that off.


I understand that, but it seems the whole problem of people overwriting 
there data dir is because we initdb from the start script.  If we 
installed the datadir during the RPM install, it would still be newbie 
friendly and would removed initdb from start script solving that problem.


 initdb will not overwrite an existing installation.

Joshua D. Drake





The only downside is larger disk foot-print for something that a user 
may never use.  Given the size of todays hard drives, and the size of a 
standard RedHat install, I don't think that is much of an issue.


---(end of broadcast)---
TIP 6: explain analyze is your friend




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


Re: [HACKERS] [Pgsqlrpms-hackers] Safer auto-initdb for RPM init

2006-08-26 Thread Matthew T. O'Connor

Jim C. Nasby wrote:

On Sat, Aug 26, 2006 at 01:32:17PM -0700, Joshua D. Drake wrote:
I am not exactly sure why we initdb at all. IMHO it would be better if 
the start script just checked if there was a cluster. If not, it 
wouldn't start, it would error with: You do not have a cluster, please 
read man page on initdb.


As Tom mentioned, it's for newbie-friendliness. While I can understand
that, I think it needs to be easy to shut that off.


I understand that, but it seems the whole problem of people overwriting 
there data dir is because we initdb from the start script.  If we 
installed the datadir during the RPM install, it would still be newbie 
friendly and would removed initdb from start script solving that problem.


The only downside is larger disk foot-print for something that a user 
may never use.  Given the size of todays hard drives, and the size of a 
standard RedHat install, I don't think that is much of an issue.


---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] [Pgsqlrpms-hackers] Safer auto-initdb for RPM init

2006-08-26 Thread Andrew Dunstan



Jim C. Nasby wrote:

On Fri, Aug 25, 2006 at 07:21:50AM -0700, Joe Conway wrote:
  
We also decided to turn off the init script execution entirely. The DBAs 
were more comfortable with a manual database startup for a production 
machine anyway (this is the way they typically handle Oracle databases 
also). They get paged if the server ever goes down unplanned, and in 
that event they like to check things out before bringing the db back up. 
For planned outages, database startup is simply part of the plan.



I'd *really* like to have an official way to just disable the initdb
code entirely.
  


Well, in the case of RPMS built with the pgfoundry pgsqlrpms project 
init script, it looks to me like it is already disabled: see 
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsqlrpms/patches/8.2/postgresql.init?rev=1.2&content-type=text/x-cvsweb-markup


In the case of Redhat/Fedora supplied RPMs, presumably it is not 
disabled as a matter of policy, the idea being to make starting postgres 
as easy as possible. What you could do is to ask them to add some code 
to honor the setting of a variable called say, PG_INITDB, which you 
would set in the appropriate place in /etc/sysconfig.


cheers

andrew

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [HACKERS] [Pgsqlrpms-hackers] Safer auto-initdb for RPM init

2006-08-26 Thread Jim C. Nasby
On Sat, Aug 26, 2006 at 01:32:17PM -0700, Joshua D. Drake wrote:
> Jim C. Nasby wrote:
> >On Fri, Aug 25, 2006 at 07:21:50AM -0700, Joe Conway wrote:
> >>We also decided to turn off the init script execution entirely. The DBAs 
> >>were more comfortable with a manual database startup for a production 
> >>machine anyway (this is the way they typically handle Oracle databases 
> >>also). They get paged if the server ever goes down unplanned, and in 
> >>that event they like to check things out before bringing the db back up. 
> >>For planned outages, database startup is simply part of the plan.
> >
> >I'd *really* like to have an official way to just disable the initdb
> >code entirely.
> 
> I am not exactly sure why we initdb at all. IMHO it would be better if 
> the start script just checked if there was a cluster. If not, it 
> wouldn't start, it would error with: You do not have a cluster, please 
> read man page on initdb.

As Tom mentioned, it's for newbie-friendliness. While I can understand
that, I think it needs to be easy to shut that off.
-- 
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] [Pgsqlrpms-hackers] Safer auto-initdb for RPM init

2006-08-26 Thread Joshua D. Drake

Jim C. Nasby wrote:

On Fri, Aug 25, 2006 at 07:21:50AM -0700, Joe Conway wrote:
We also decided to turn off the init script execution entirely. The DBAs 
were more comfortable with a manual database startup for a production 
machine anyway (this is the way they typically handle Oracle databases 
also). They get paged if the server ever goes down unplanned, and in 
that event they like to check things out before bringing the db back up. 
For planned outages, database startup is simply part of the plan.


I'd *really* like to have an official way to just disable the initdb
code entirely.


I am not exactly sure why we initdb at all. IMHO it would be better if 
the start script just checked if there was a cluster. If not, it 
wouldn't start, it would error with: You do not have a cluster, please 
read man page on initdb.


Joshua D. Drake


--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] [Pgsqlrpms-hackers] Safer auto-initdb for RPM init script

2006-08-26 Thread Jim C. Nasby
On Fri, Aug 25, 2006 at 07:21:50AM -0700, Joe Conway wrote:
> We also decided to turn off the init script execution entirely. The DBAs 
> were more comfortable with a manual database startup for a production 
> machine anyway (this is the way they typically handle Oracle databases 
> also). They get paged if the server ever goes down unplanned, and in 
> that event they like to check things out before bringing the db back up. 
> For planned outages, database startup is simply part of the plan.

I'd *really* like to have an official way to just disable the initdb
code entirely.
-- 
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] [Pgsqlrpms-hackers] Safer auto-initdb for RPM init script

2006-08-25 Thread Joe Conway

Tom Lane wrote:

We've seen more than one report of corruption of PG databases that
seemed to be due to the willingness of the RPM init script to run
initdb if it thinks the data directory isn't there.  This is pretty
darn risky on an NFS volume, for instance, which might be offline
at the instant the script looks.  The failure case is

- script doesn't see data directory
- script runs initdb and starts postmaster
- offline volume comes online
- KABOOM


Been there, done exactly that...



I can still imagine ways for this to fail, eg if you run an RPM
install or upgrade while your mountable data directory is offline.
But it ought to be an order of magnitude safer than things are now.
(Hm, maybe the %post script should only run during an RPM install,
not an upgrade.)


That's probably a good plan.



Comments?  Anyone see a better way?


I can't think of any offhand that aren't too expensive. We ended up 
putting a root-owned empty data directory beneath the mount point, but 
that can't be automated.


We also decided to turn off the init script execution entirely. The DBAs 
were more comfortable with a manual database startup for a production 
machine anyway (this is the way they typically handle Oracle databases 
also). They get paged if the server ever goes down unplanned, and in 
that event they like to check things out before bringing the db back up. 
For planned outages, database startup is simply part of the plan.


Joe

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org