My point/question is: when I've seen this before and recovery mode is
taking on the order of minutes, I find that doing:
pg_ctl stop -m i
pg_ctl start
is faster (on the order of seconds) than letting postgres finish
recovery mode. So I wonder:
1. Is this safe from a data integrity point of view
> "TFO" == Thomas F O'Connell writes:
TFO> Which brings up a follow-up question: is it documented anywhere
TFO> exactly what goes on in recovery mode? If so, I've not found it.
TFO> When I've experienced this, it has seemed quicker just to stop and
TFO> restart postgres than to let recovery
On Tue, Feb 08, 2005 at 07:31:13AM -0500, Jim Wilson wrote:
> That\'s unfortunate. I\'ve tried to explain my position off list to
> Marco, but it really isn\'t worth debating. FWIW I think this thread
> was started by someone with application issues. The fact is, such
> things happen.
Well, I r
On Tue, 8 Feb 2005, Jim Wilson wrote:
Your application should handle failures in the middle of a
transaction,
connection failures included, in a graceful but correct way.
It does very well, until the next bug is discovered.
I see your point (being able to safely shut a connection down on the
server
>
> Your application should handle failures in the middle of a
transaction,
> connection failures included, in a graceful but correct way.
It does very well, until the next bug is discovered.
>
> I see your point (being able to safely shut a connection down on the
> server side), but it\'s at t
On Fri, 4 Feb 2005, Jim Wilson wrote:
regards, tom lane
We\'d like to be able to take out a connection without risking
postmaster going
down and thus losing all uncommitted data.
Unfortunately the whole world isn\'t encapsulated in Postgres
transactions or we
would never have to worry about unco
> On Fri, Feb 04, 2005 at 05:01:43PM -0500, Jim Wilson wrote:
>
> > Rather than getting into the raised eyebrow thing , I\\\'d
suggest
> > checking your "qualifiers". Consider that with Postgres, if killing
a
> > single connection brings the whole server down, you will loose
_all_
> > uncommit
> Jim Wilson <[EMAIL PROTECTED]> writes:
> > Rather than getting into the raised eyebrow thing , I\\\'d
suggest
> > checking your "qualifiers". Consider that with Postgres, if killing
a
> > single connection brings the whole server down, you will loose
_all_
> > uncommitted data. If you did not
Jim Wilson <[EMAIL PROTECTED]> writes:
> Rather than getting into the raised eyebrow thing ;-), I\\\'d suggest
> checking your "qualifiers". Consider that with Postgres, if killing a
> single connection brings the whole server down, you will loose _all_
> uncommitted data. If you did not, then I wo
On Fri, Feb 04, 2005 at 05:01:43PM -0500, Jim Wilson wrote:
> Rather than getting into the raised eyebrow thing ;-), I\\\'d suggest
> checking your "qualifiers". Consider that with Postgres, if killing a
> single connection brings the whole server down, you will loose _all_
> uncommitted data. If
> Jim Wilson <[EMAIL PROTECTED]> writes:
> > If you are not very careful about how you handle orphaned
connections
> > in Postgres you will likely lose datanot "maybe" like a long
> > shot...but "likely".
>
> [ raised eyebrow ... ] Say again? I don\'t know of any reason why a
> lost connecti
Jim Wilson <[EMAIL PROTECTED]> writes:
> If you are not very careful about how you handle orphaned connections
> in Postgres you will likely lose datanot "maybe" like a long
> shot...but "likely".
[ raised eyebrow ... ] Say again? I don't know of any reason why a
lost connection would cause
> On Fri, Feb 04, 2005 at 01:44:10PM -0600, Thomas F.O\'Connell wrote:
> > Is there any stronger medicine that\'s available (for instance, when
a
> > backend won\'t respond to SIGTERM) and has no unfortunate side
effects?
> > I just ran into this situation the other day (and made the
unfortunate
Which brings up a follow-up question: is it documented anywhere exactly
what goes on in recovery mode? If so, I've not found it.
When I've experienced this, it has seemed quicker just to stop and
restart postgres than to let recovery mode complete. Is that unsafe?
-tfo
--
Thomas F. O'Connell
Co
On Fri, Feb 04, 2005 at 01:44:10PM -0600, Thomas F.O'Connell wrote:
> Is there any stronger medicine that's available (for instance, when a
> backend won't respond to SIGTERM) and has no unfortunate side effects?
> I just ran into this situation the other day (and made the unfortunate
> discover
Is there any stronger medicine that's available (for instance, when a
backend won't respond to SIGTERM) and has no unfortunate side effects?
I just ran into this situation the other day (and made the unfortunate
discovery that SIGABRT is as bad as SIGKILL as far as a postmaster is
concerned).
16 matches
Mail list logo
