From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
Cc: | Postgres general mailing list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: too many trigger records found for relation "item" - |
Date: | 2007-01-26 06:19:41 |
Message-ID: | 18673.1169792381@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Csaba Nagy <nagy(at)ecircle-ag(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Csaba Nagy | 2007-01-26 09:06:46 | Re: too many trigger records found for relation "item" - |
Previous Message | brian stone | 2007-01-26 05:02:58 | Re: bytea performance issue |