Re: [PERFORM] Strange performance degradation - Mailing list pgsql-general

From Denis Lussier
Subject Re: [PERFORM] Strange performance degradation
Date
Msg-id ba8cf61c0911241547q3657ef33g24944ebd93e179e4@mail.gmail.com
Whole thread Raw
In response to Re: [PERFORM] Strange performance degradation  (Matthew Wakeling <matthew@flymine.org>)
Responses Re: [PERFORM] Strange performance degradation  (Matthew Wakeling <matthew@flymine.org>)
List pgsql-general
Bouncing the app will roll back the transactions.  If there were any
pending updates/inserts, wouldn't he be able to see them in one of the
system tables...


On 11/24/09, Matthew Wakeling <matthew@flymine.org> wrote:
> On Tue, 24 Nov 2009, Denis Lussier wrote:
>> IMHO the client application is already confused and it's in Prod.
>> Shouldn't he perhaps terminate/abort the IDLE connections in Prod and
>> work on correcting the problem so it doesn't occur in Dev/Test??
>
> The problem is, the connection isn't just IDLE - it is idle IN
> TRANSACTION. This means that there is quite possibly some data that has
> been modified in that transaction. If you kill the backend, then that will
> automatically roll back the transaction, and all of those changes would be
> lost.
>
> I agree that correcting the problem in dev/test is the priority, but I
> would be very cautious about killing transactions in production. You don't
> know what data is uncommitted. The safest thing to do may be to bounce the
> application, rather than Postgres.
>
> Matthew
>
> --
>  All of this sounds mildly turgid and messy and confusing... but what the
>  heck. That's what programming's all about, really
>                                         -- Computer Science Lecturer
>

pgsql-general by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Re: I need help creating a composite type with some sort of constraints.
Next
From: "Michael Lawson (mshindo)"
Date:
Subject: Processing Delay