From: | "Dorochevsky,Michel" <michel(dot)dorochevsky(at)softcon(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-bugs(at)postgresql(dot)org, Dave Page <dpage(at)postgresql(dot)org> |
Subject: | Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect |
Date: | 2007-04-23 17:28:22 |
Message-ID: | C12B71B21705A04C9B9C3E9300430CAFA97107@jupiter.softcon-its.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers pgsql-patches |
-----Ursprüngliche Nachricht-----
> Von: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> > "Dorochevsky,Michel" <michel(dot)dorochevsky(at)softcon(dot)de> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-04-23 18:51:51 | Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect |
Previous Message | Tom Lane | 2007-04-23 16:56:04 | Re: BUG #3245: PANIC: failed to re-find shared loc k o b ject |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Hammond | 2007-04-23 18:10:29 | TODO idea - implicit constraints across child tables with a common column as primary key (but obviously not a shared index) |
Previous Message | Magnus Hagander | 2007-04-23 16:44:54 | Re: BUG #3242: FATAL: could not unlock semaphore: error code 298 |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-04-23 18:51:51 | Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect |
Previous Message | Zeugswetter Andreas ADI SD | 2007-04-23 15:37:38 | Re: [HACKERS] Full page writes improvement, code update |