On Fri, 2 Oct 2009, Tom Lane wrote:
The people who hollered loudest about this seemed to often have
long-running read-only transactions in parallel with lots of short
read-write transactions.
Which makes sense if you think about it. Long-running read-only reports
are quite common in DBA lan
"Kevin Grittner" writes:
> Tom Lane wrote:
>> As of 8.4, the typical case is that an open transaction blocks
>> deletion of rows that were deleted since the transaction's current
>> *statement* started.
[ BTW, of course that should have read "blocks removal of" ... ]
> Surely the original ver
Tom Lane wrote:
> As of 8.4, the typical case is that an open transaction blocks
> deletion of rows that were deleted since the transaction's current
> *statement* started. So this makes a huge difference if you have
> long-running transactions that consist of a series of not-so-long
> stateme
Greg Smith writes:
> 2) Test if an upgrade to PG 8.4 improves your situation. There is some
> new code in that version (labeled in the release notes as "Track
> transaction snapshots more carefully") that has improved problems in this
> area quite a bit for me. There's a bit more detail about
On Thu, 24 Sep 2009, jes...@krogh.cc wrote:
I have a transaction running at the database for around 20 hours .. still
isn't done. But during the last hours it has come to the point where it
really hurts performance of "other queries".
Open transactions grab an internal resource named a snapsho
2009/9/24 :
>> On Thu, Sep 24, 2009 at 9:27 AM, wrote:
>>
>>> Hi.
>>>
>>> I have a transaction running at the database for around 20 hours ..
>>> still
>>> isn't done. But during the last hours it has come to the point where it
>>> really hurts performance of "other queries".
>>>
>>> Given pg_sta
> On Thu, Sep 24, 2009 at 9:27 AM, wrote:
>
>> Hi.
>>
>> I have a transaction running at the database for around 20 hours ..
>> still
>> isn't done. But during the last hours it has come to the point where it
>> really hurts performance of "other queries".
>>
>> Given pg_stat_activity output there
> On Thu, Sep 24, 2009 at 2:27 AM, wrote:
>> Hi.
>>
>> I have a transaction running at the database for around 20 hours ..
>> still
>> isn't done. But during the last hours it has come to the point where it
>> really hurts performance of "other queries".
>
> What is your transaction doing during
On Thu, Sep 24, 2009 at 2:27 AM, wrote:
> Hi.
>
> I have a transaction running at the database for around 20 hours .. still
> isn't done. But during the last hours it has come to the point where it
> really hurts performance of "other queries".
What is your transaction doing during this time?
>
On Thu, Sep 24, 2009 at 9:27 AM, wrote:
> Hi.
>
> I have a transaction running at the database for around 20 hours .. still
> isn't done. But during the last hours it has come to the point where it
> really hurts performance of "other queries".
>
> Given pg_stat_activity output there seems to be
> I have a transaction running at the database for around 20 hours .. still
> isn't done. But during the last hours it has come to the point where it
> really hurts performance of "other queries".
>
> Given pg_stat_activity output there seems to be no locks interfering but
> the overall cpu-usage o
11 matches
Mail list logo