Andres Freund wrote:
> On 2014-02-14 08:06:40 +0100, Jesper Krogh wrote:
> > The build in mechanism, that cleanup is i cost paid by the process who
> > happened to fill the pendinglist, is really hard to deal with in
> > production. More control is appreciated, perhaps even an explicit
> > flush-m
On 2014-02-14 08:06:40 +0100, Jesper Krogh wrote:
> On 14/02/14 00:49, Tom Lane wrote:
> >Andres Freund writes:
> >>On 2014-02-13 16:15:42 -0500, Tom Lane wrote:
> >>>Something like the attached? Can somebody who's seen this problem confirm
> >>>this improves matters?
> >>Hm. Won't that possiby l
On 14/02/14 00:49, Tom Lane wrote:
Andres Freund writes:
On 2014-02-13 16:15:42 -0500, Tom Lane wrote:
Something like the attached? Can somebody who's seen this problem confirm
this improves matters?
Hm. Won't that possiby lead to the fast tuple list growing unboundedly?
I think we would nee
On 2014-02-13 18:49:21 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-02-13 16:15:42 -0500, Tom Lane wrote:
> >> Something like the attached? Can somebody who's seen this problem confirm
> >> this improves matters?
>
> > Hm. Won't that possiby lead to the fast tuple list growing unbo
Andres Freund writes:
> On 2014-02-13 16:15:42 -0500, Tom Lane wrote:
>> Something like the attached? Can somebody who's seen this problem confirm
>> this improves matters?
> Hm. Won't that possiby lead to the fast tuple list growing unboundedly?
> I think we would need to at least need to stop
On 2014-02-13 16:15:42 -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > Perhaps we should use a lock to enforce that only one process tries to
> > clean up the pending list at a time.
>
> Something like the attached? Can somebody who's seen this problem confirm
> this improves matters?
>
Heikki Linnakangas writes:
> Perhaps we should use a lock to enforce that only one process tries to
> clean up the pending list at a time.
Something like the attached? Can somebody who's seen this problem confirm
this improves matters?
(ginInsertCleanup's header comment also needs to be rewritt
On 02/13/2014 10:58 AM, Heikki Linnakangas wrote:
Perhaps we should use a lock to enforce that only one process tries to
clean up the pending list at a time.
Is that going to serialize all these inserts?
It will serialize the cleanup process, which moves entries from the
pending list to th
On 02/13/2014 05:40 PM, Andrew Dunstan wrote:
On 02/12/2014 04:04 PM, Heikki Linnakangas wrote:
On 02/12/2014 10:50 PM, Andres Freund wrote:
On February 12, 2014 9:33:38 PM CET, Tom Lane wrote:
Andres Freund writes:
On 2014-02-12 14:39:37 -0500, Andrew Dunstan wrote:
On investigation I fo
On 02/12/2014 04:04 PM, Heikki Linnakangas wrote:
On 02/12/2014 10:50 PM, Andres Freund wrote:
On February 12, 2014 9:33:38 PM CET, Tom Lane wrote:
Andres Freund writes:
On 2014-02-12 14:39:37 -0500, Andrew Dunstan wrote:
On investigation I found that a number of processes were locked
wai
On 02/12/2014 10:50 PM, Andres Freund wrote:
On February 12, 2014 9:33:38 PM CET, Tom Lane wrote:
Andres Freund writes:
On 2014-02-12 14:39:37 -0500, Andrew Dunstan wrote:
On investigation I found that a number of processes were locked
waiting for
one wedged process to end its transaction,
On February 12, 2014 9:33:38 PM CET, Tom Lane wrote:
>Andres Freund writes:
>> On 2014-02-12 14:39:37 -0500, Andrew Dunstan wrote:
>>> On investigation I found that a number of processes were locked
>waiting for
>>> one wedged process to end its transaction, which never happened
>(this
>>> transa
On 02/12/2014 02:50 PM, Andres Freund wrote:
On 2014-02-12 14:39:37 -0500, Andrew Dunstan wrote:
On investigation I found that a number of processes were locked waiting for
one wedged process to end its transaction, which never happened (this
transaction should normally take milliseconds). opro
Andres Freund writes:
> On 2014-02-12 14:39:37 -0500, Andrew Dunstan wrote:
>> On investigation I found that a number of processes were locked waiting for
>> one wedged process to end its transaction, which never happened (this
>> transaction should normally take milliseconds). oprofile revealed t
* Andres Freund (and...@2ndquadrant.com) wrote:
> There's previously been talk about changing the limits to something more
> reasonable but it got stalled in bikeshedding IIRC.
As I recall, there was argument that we didn't really need a new GUC for
this (which was the proposal) but rather just ne
On 2014-02-12 14:39:37 -0500, Andrew Dunstan wrote:
> On investigation I found that a number of processes were locked waiting for
> one wedged process to end its transaction, which never happened (this
> transaction should normally take milliseconds). oprofile revealed that
> postgres was spending
A client of ours encountered this problem when upgrading (via slony)
from 8.4 to 9.2, and then from 8.4 to to 9.3. The application is a
telephony app that inserts call records at pretty hight volume in the
busiest part of the day, which usually starts around 10.00 am to 11.00
am US eastern time
17 matches
Mail list logo
