Re: [GENERAL] Getting "insufficient data left in message" on copy with binary

2009-09-05 Thread Tom Lane
Gordon Shannon writes: > Got it. The problem was a combination of 2 mis-matched data types. > ... > So, my fault, and the fix is obvious. But it does seem like a less than > ideal error message. The binary format is sufficiently non-redundant that it's hard for the code to know just what is wr

Re: [GENERAL] PG connections going to 'waiting'

2009-09-05 Thread Chris Barnes
Is the any way to look at the statistics on the name of table, length and type over a period of time? Or, would we have to use munin and capture these stats for analysis later? Chris > To: alan.mc...@gmail.com > CC: pgsql-general@postgresql.org > Subject: Re: [GENERAL] PG connections go

Re: [GENERAL] easy task: concurrent select-updates

2009-09-05 Thread Andy Colson
Nickolay wrote: Kevin McConnell wrote: CREATE OR REPLACE FUNCTION public.getmsg() RETURNS integer LANGUAGE plpgsql AS $function$ declare rec record; begin for rec in select id from msg where busy =alse order by id loop update msg set busy =rue where id = rec.id and bus

Re: [GENERAL] PG connections going to 'waiting'

2009-09-05 Thread Joshua Tolley
On Sat, Sep 05, 2009 at 01:08:30PM -0400, Alan McKay wrote: > > pg_locks?  Somebody taking exclusive lock on a widely-used table might > > explain that. > > OK, in theory we could do the following, no? > > Use our PITR logs to restore a tertiary system to the point when we > were having the probl

Re: [GENERAL] PG connections going to 'waiting'

2009-09-05 Thread Tom Lane
Alan McKay writes: >> pg_locks?  Somebody taking exclusive lock on a widely-used table might >> explain that. > OK, in theory we could do the following, no? > Use our PITR logs to restore a tertiary system to the point when we > were having the problem (we have a pretty wide 2 or 3 hour window t

Re: [GENERAL] PG connections going to 'waiting'

2009-09-05 Thread Alan McKay
> pg_locks?  Somebody taking exclusive lock on a widely-used table might > explain that. OK, in theory we could do the following, no? Use our PITR logs to restore a tertiary system to the point when we were having the problem (we have a pretty wide 2 or 3 hour window to hit), then query the pg_lo

Re: [GENERAL] PG connections going to 'waiting'

2009-09-05 Thread Alan McKay
> pg_locks?  Somebody taking exclusive lock on a widely-used table might > explain that. Thanks, I'll check with the SW designers and DB admin. -- “Don't eat anything you've ever seen advertised on TV” - Michael Pollan, author of "In Defense of Food" -- Sent via pgsql-general mailing

Re: [GENERAL] PG connections going to 'waiting'

2009-09-05 Thread Tom Lane
Alan McKay writes: > I've got Munin installed on all my systems, so was able to get some > interesting data around the big crash we had last night. We'd > thought it was simply a matter of our DB connections maxing out, but > it looks a bit more complex than that. A good 2 or 3 hours before the

[GENERAL] PG connections going to 'waiting'

2009-09-05 Thread Alan McKay
Hey folks, I've got Munin installed on all my systems, so was able to get some interesting data around the big crash we had last night. We'd thought it was simply a matter of our DB connections maxing out, but it looks a bit more complex than that. A good 2 or 3 hours before the connections max

Re: [GENERAL] Create language PLPERL error

2009-09-05 Thread Shakil Shaikh
-- From: "Alvaro Herrera" Shakil Shaikh wrote: ERROR: could not access file "$libdir/plperl": No such file or directory Apparently this means that the version of Postgresql I have wasn't compiled with support for plperl. How would I find this