Tom Lane wrote: > Simon has a legitimate objection; not that there's no bug, but that the > probability of getting bitten is exceedingly small.
Oh, if that's what he meant, he's right. > The test script you > showed cheats six-ways-from-Sunday to cause an OID collision that would > never happen in practice. The only case where it would really happen > is if a table that has existed for a long time (~ 2^32 OID creations) > gets dropped and then you're unlucky enough to recycle that exact OID > before the next checkpoint --- and then crash before the checkpoint. Yeah, it's unlikely to happen, but the consequences are horrible. Note that it's not just DROP TABLE that's a problem, but anything that uses smgrscheduleunlink, including CLUSTER and REINDEX. > I tend to agree that truncating the file, and extending the fsync > request mechanism to actually delete it after the next checkpoint, > is the most reasonable route to a fix. Ok, I'll write a patch to do that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
