Csaba Nagy <nagy@xxxxxxxxxxxxxx> writes: >> Well, if you can show a reproducible test case, I'd like to look at it. > OK, I have a test case which has ~ 90% success rate in triggering the > issue on my box. It is written in Java, hope you can run it, in any case > you'll get the idea how to reproduce the issue. Hm, well the trigger-related complaints are pretty obviously from a known race condition: pre-8.2 we'd read the pg_class row for a table before obtaining any lock on the table. So if someone else was concurrently adding or deleting triggers then the value of pg_class.reltriggers could be wrong by the time we'd managed to acquire any lock. I believe this is fixed as of 8.2 --- can you duplicate it there? (No, backpatching the fix is not practical.) > The code is attached, and I list here some typical output run against an > 8.1.3 postgres installation. The first exception is strange on it's own, > it was produced after a few runs, might be caused by another issue with > creating/dropping tables (I think I have seen this too some time ago). How sure are you about that uninterlocked getChildTableName() thing? It's possible to get a failure complaining about duplicate type name instead of duplicate relation name during CREATE TABLE, if the timing is just right. regards, tom lane
