On 7/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Notice that recursiveDeletion() tries to clean out pg_depend before
it actually deletes the target object, and in the current code that
object-specific subroutine is the only thing that takes any sort of lock.

In the past 4-6 months, we've seen 4 cases that look like logical
catalog corruption in the area of dependencies and, likely, concurrent
activity.  I don't recall the exact releases off-hand, but 1 case was
on 8.1 and the others were on 8.2.  In two of the cases, there were
DDL changes while running Slony (which we originally attributed to
Slony).  The other two cases were normal DDL including ALTER TABLE ADD

Unfortunately, we were not able to acquire a forensic copy of the
databases for further analysis.  In all cases, the hardware behaved
and tested fine.  But, it looks dependency-related as in all cases,
dependency records existed for views and indexes which no longer
existed in pg_class (the files and records were gone)

Sorry I don't have more information available right now, but this is
an area that requires further investigation.

Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation            | fax: 732.331.1301
33 Wood Ave S, 3rd Floor            | [EMAIL PROTECTED]
Iselin, New Jersey 08830            | http://www.enterprisedb.com/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to