Re: Why copy_relation_data only use wal whenWALarchivingis enabled

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