Re: Postgres Access Timing

[beamends <..hidden..>]

On Fri, 2009-07-24 at 12:39 +0100, beamends wrote:
> On Thu, 2009-07-23 at 09:00 -0700, Chris Travers wrote:
> > 
> > 

<snip>

>  
> > Hmmm....  I don't think it would be a timing issue unless you are
> > doing strange things.  Do you have errors from the PostgreSQL log
> > file?
> > 
> > Best Wishes,
> > Chris Travers
> > 
> 
> Hi Chris,
> I'll have a look for the log - wherever it is!
> 
> More info from this mornings efforts....
> 
> For about an hour and a half all was well, then it started messing
> about, INSERTing from the C program failing, but using exactly the same
> line (cut and pasted into phppgsadmin from the output on the terminal)
> worked. Then that stopped working too! Currently using phppgadmin's SQL
> window will work, but it can take up to 4 minutes before success. I also
> tried updating the partsvendor info from the part window, and this too
> fails - repeatedly coming up with a unique key error (despite the entry
> not being there browsing with phppgadmin) until suddenly, for no reason,
> it works!
> 
> All the other tables associated with a part record work fine - is there
> something special about partsvendor - it seems like updates to that
> table are being queued and overflowing after a while?
> 
> Cheers
> Richard  

Naughty following up my own post, but....

I've found the log, but it's not over helpful - postgres just says
there's a unique key error. 

Just a thought though, could it be the nextval bit in

INSERT INTO partsvendor (vendor_id, parts_id, partnumber, leadtime,
lastcost, entry_id, curr) 
VALUES (10213, 54379, 'DGD000040PMA', 1, 16.05,
nextval('partsvendor_entry_id_seq'::regclass), 'GBP');

that's causing the problem - apart from creating a part, this is the
only other time such a thing gets used, and the parts table is indeed
54370 rows if that makes any odds?

Cheers
Richard