-----Ursprüngliche Nachricht-----
> Von: Tom Lane [mailto:[EMAIL PROTECTED]
> > "Dorochevsky,Michel" <[EMAIL PROTECTED]> writes:
> > Here are two panic runs with the Heikki's LOCK_DEBUG patched postgres:
> > www.dorochevsky.de/infos/PostgresPanicProblem-2007-04-23.zip
>
> Ok, this does provide a new clue: the problem table is being locked
> twice (under two different lock types) in the transaction, and for
> some reason the lock object is discarded after the first of these is
> released. Furthermore, it looks like both of the references arise
> indirectly from foreign-key operations.
>
> Since realizing that your test case doesn't seem to be doing anything
> unusual, I've been trying to reproduce it here by tweaking the pgbench
> script to use COMMIT PREPARED instead of just COMMIT. No luck so far,
> but the pgbench test hasn't got any foreign keys, and maybe that's
> important. Can you show us the schema of your database? (pg_dump -s
> output would be great.)
>
Tom,
I am not used to the command line tools. So I made a backup
using the pgadmin GUI. I selected options 'PLAIN format', 'with OIDs' and
'schema only'. See
www.dorochevsky.de/infos/TestSchema.txt
I hope that is what you needed. If not: Could you give me instructions
which options to use in the GUI tool?
> Also, if you haven't rebuilt the schema since the second of these runs,
> which table has OID 433757 now? I think it must be
> requiredqualities_numb5b1c0a0a but would like to confirm that.
>
Table requiredqualities_num5b1c0a0a has OID 43755.
OID 433757 identifies requiredqualities_num5b1c0a0a_pkey which is a primary
key constraint for this table containing both fields of the table.
(The table is used to represent a n:m association between the tables
'action' and 'quality'.)
Best Regards
-- Michel
