Re: We should Axe /contrib/start-scripts - Mailing list pgsql-hackers

From Tom Lane
Subject Re: We should Axe /contrib/start-scripts
Date
Msg-id 29925.1250719980@sss.pgh.pa.us
Whole thread Raw
In response to Re: We should Axe /contrib/start-scripts  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: We should Axe /contrib/start-scripts  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: We should Axe /contrib/start-scripts  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Right -- we did run into this in spades when our backup server,
> running dozens of instances of PostgreSQL in "warm standby" to confirm
> the integrity of the files received, crashed hard.  I wasn't sure if
> this was the problem being addressed.  One obvious solution, which we
> now rigorously observe, is to use a different OS user for each
> PostgreSQL instance.  I assume that pg_ctl is safe in such an
> environment?

Well, using a different user per instance is a good idea because then
the safety analysis I gave holds rigorously for each instance.  It
doesn't get you out of the problem by itself, because the problem as
described can happen with just one instance.
> It must buy something in our environment, because our attempts to use
> the sample script with minimal modification were problematic. 
> Unfortunately I forget the details, but our problems vanished when we
> switched to pg_ctl.  (Well, except for that one unfortunate episode
> mentioned above.)

Hmm.  As stated, I would expect pg_ctl to make it worse.  It would be
interesting to have a closer look at your before-and-after scripts.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: We should Axe /contrib/start-scripts
Next
From: Tom Lane
Date:
Subject: Re: We should Axe /contrib/start-scripts