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
