On 4/19/15 9:53 PM, Tim Uckun wrote:
On Sat, Apr 18, 2015 at 10:24 AM, Pawel Veselov mailto:pawel.vese...@gmail.com>> wrote:
I found some dangling prepared transactions
How do you find and remove these?
SELECT * FROM pg_prepared_xacts;
ROLLBACK PREPARED xid;
--
Jim Nasby, Data Architec
​Thanks for the insight.
Pai-Hung
On Sat, Apr 18, 2015 at 10:24 AM, Pawel Veselov
wrote:
> I found some dangling prepared transactions
How do you find and remove these?
Using Apache camel
Listen/notify ->PGEvent Component (http://camel.apache.org/pgevent.html) ->
Mail Component (http://camel.apache.org/mail.html)
You can also then handle all the exceptions of the email server easily.
On Sun, Apr 19, 2015 at 6:42 AM, Jim Nasby wrote:
> On 4/18/15 12:52 AM, Dav
On 4/19/15 3:08 PM, Jim Nasby wrote:
> I do suspect your pgfree/s is very high though; putting 200k
pages/s on
> the free list seems like something's broken.
>
The system has constant and considerable load of small writes. The
pg_activity tool shows 300 IOPs sustained (it claims max IPs above
On 4/19/15 4:24 AM, Andomar wrote:
To put the top question first:
How can table extension locks explain a a massive spike in CPU usage?
I can imagine 400 connections waiting on disk I/O, but then, wouldn't
they all be sleeping?
Not necessarily. Spinlocks don't put the process to sleep, but th
On Sun, Apr 19, 2015 at 9:34 AM, rob stone wrote:
>
>
>
> On Fri, 2015-04-17 at 16:16 -0700, Adrian Klaver wrote:
> > On 04/17/2015 03:09 PM, rob stone wrote:
> > > Hello,
> > >
> > > I'm trying to upgrade from 9.3 to 9.4 on my laptop and encountering
> this
> > > error:-
> > >
> > >
> > > postgr
On Fri, 2015-04-17 at 16:16 -0700, Adrian Klaver wrote:
> On 04/17/2015 03:09 PM, rob stone wrote:
> > Hello,
> >
> > I'm trying to upgrade from 9.3 to 9.4 on my laptop and encountering this
> > error:-
> >
> >
> > postgres@roblaptop:/usr/lib/postgresql/9.4/bin$ ./pg_upgrade
> > -b /usr/lib/post
To put the top question first:
How can table extension locks explain a a massive spike in CPU usage?
I can imagine 400 connections waiting on disk I/O, but then, wouldn't
they all be sleeping?
> Ok, that's a MAJOR hint, because relation 1249 is a system catalog;
> namely pg_attribute. So I th
