Tom Lane wrote:
"Dorochevsky,Michel" <[EMAIL PROTECTED]> writes: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.Yeah, this is great, particularly since it includes the OIDs. However, the OIDs don't seem to entirely match up with the LOCK_DEBUG output. I'm wondering if somehow we're locking the wrong OIDs? Hard to believe a bug like that could've escaped detection though. Still trying to trace through it to see where things first go wrong. (If anyone else is looking at this, note that a constraint's index will generally have an OID one less than the constraint, so you can infer the OIDs of indexes that aren't explicitly given in the dump.)
It looks like the table 433757 is locked three times in the transaction. First in RowExclusive mode, and then twice in AccessShare mode. At prepare time, the proclock is correctly transfered to the dummy PGPROC, with the lock hold in both modes. But when it comes time to commit, the lock is released twice in AccessShare mode.
Locking the same lock twice is usually handled correctly, I don't understand why it fails in this case. I'm thinking that the locallock structs somehow get out of sync with the lock structs in shared memory. The twophase-records are created from the locallock structs alone, so if there's extra entries in the locallocks table for some reason, we'd get the symptoms we have.
Unless you have a better idea, I'd like to add some more debug-prints to AtPrepare_Locks to see what gets written to the state file and why.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
