Re: Why copy_relation_data only use walwhenWALarchivingis enabled - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Why copy_relation_data only use walwhenWALarchivingis enabled
Date
Msg-id 47164820.4080506@enterprisedb.com
Whole thread Raw
In response to Re: Why copy_relation_data only use wal whenWALarchivingis enabled  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Simon Riggs wrote:
> On Wed, 2007-10-17 at 18:13 +0100, Heikki Linnakangas wrote:
> 
>>> 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.
> 
> When is this going to happen?
> 
> We'd need to insert 2^32 toast chunks, which is >4 TB of data, or insert
> 2^32 large objects, or create 2^32 tables, or any combination of the
> above all within one checkpoint duration *and* exactly hit the exact
> same relation.

The consumption of the OIDs don't need to happen within one checkpoint
duration. As long as the DROP and the reuse happens in the same
checkpoint cycle, you're screwed.

Granted that you're not likely to ever experience OID wrap-around unless
you have a heavily used user table with OIDs. Or create/drop temp tables
a lot.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Why copy_relation_data only use wal whenWALarchivingis enabled
Next
From: Gregory Stark
Date:
Subject: Deprecating heap_formtuple/heap_modifytuple/heap_deformtuple