Csaba Nagy <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
