Yes, I was talking about both. According to the documentation of PostgreSQL it should work:
"nextval: Advance the sequence object to its next value and return that value. This is done atomically: even if multiple sessions execute nextval concurrently, each will safely receive a distinct sequence value."
I should probably just write a logfile with the id's of the sequence when called from db_nextval and be over with it, just to get some more hard proof. But as a matter of fact I reduced my reliance on db_nextval considerably (I use db_string "select nextval(t_acs_object_id_seq) from dual" instead) and the problem is reduced to happen only once every three or four hours (which translates into every 1.000 objects or so).
Therefore I doubt the problem is within PostgreSQL itself, it seems to be in the way db_nextval queries PostgreSQL, and one assumption was that it has to do with the sessions.
