Hi Tom, > >> Those are bugs (although there is probably only one bug and the rest is > >> collateral damage). May we have a test case? > > > > Scripts, triggers and stuff are a bit complex, before assigning the > > resources for that, could we help with creating a backtrace? > > You did show a backtrace --- it proves only what was already obvious, > namely that the problem is in transaction cleanup.
Bummer, this is not going to work.... ;( I've been trying to mimic the structure of tables, after en deferred triggers and corresponding inserts/updates, but I'm still unsuccesfull. On our development database I confirmed that it's safepoint related, but that was kind of obvious from the error as well. Can you think of another way for me to for example get more information out of the problemcase that I _can_ reproduce? It would for example help if I could get a clue on what table is involved with the problematic tuples. I could easily add extra debug/log statements to the locations these errors come from, but would appreciate a hint as to what to add exactly ;) -- Best, Frank. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
