From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Josh Berkus" <josh(at)agliodbs(dot)com>, "Chander Ganesan" <chander(at)otg-nc(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: We should Axe /contrib/start-scripts |
Date: | 2009-08-19 22:13:00 |
Message-ID: | 29925.1250719980@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-08-19 22:18:58 | Re: We should Axe /contrib/start-scripts |
Previous Message | Greg Stark | 2009-08-19 21:52:32 | Re: We should Axe /contrib/start-scripts |