Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Why copy_relation_data only use wal whenWALarchivingis enabled

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Patches" <pgsql-patches(at)postgresql(dot)org>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Simon Riggs" <simon(at)2ndquadrant(dot)com>,"Jacky Leng" <lengjianquan(at)163(dot)com>
Subject: Re: [HACKERS] Why copy_relation_data only use wal whenWALarchivingis enabled
Date: 2007-10-20 14:14:26
Message-ID: 471A0D42.1020507@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Here's an updated version of the patch. There was a bogus assertion in
the previous one, comparing against mdsync_cycle_ctr instead of
mdunlink_cycle_ctr.

Heikki Linnakangas wrote:
> Tom Lane wrote:
>> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>>> The best I can think of is to rename the obsolete file to
>>> <relfilenode>.stale, when it's scheduled for deletion at next
>>> checkpoint, and check for .stale-suffixed files in GetNewRelFileNode,
>>> and delete them immediately in DropTableSpace.
>> This is getting too Rube Goldbergian for my tastes.  What if we just
>> make DROP TABLESPACE force a checkpoint before proceeding?
> 
> Patch attached.
> 
> The scenario we're preventing is still possible if for some reason the
> latest checkpoint record is damaged, and we start recovery from the
> previous checkpoint record. I think the probability of that happening,
> together with the OID wrap-around and hitting the relfilenode of a
> recently deleted file with a new one, is low enough to not worry about.
> If we cared, we could fix it by letting the files to linger for two
> checkpoint cycles instead of one.

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

Attachment: avoid-premature-relfilenode-reuse-2.patch
Description: text/x-diff (13.4 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Trevor TalbotDate: 2007-10-20 16:40:20
Subject: Re: 8.2.3: Server crashes on Windows using Eclipse/Junit
Previous:From: Rainer BauerDate: 2007-10-20 11:22:56
Subject: Re: 8.2.3: Server crashes on Windows using Eclipse/Junit

pgsql-patches by date

Next:From: Luke LonerganDate: 2007-10-20 17:19:43
Subject: Re: Including Snapshot Info with Indexes
Previous:From: Martijn van OosterhoutDate: 2007-10-20 08:30:43
Subject: Re: Including Snapshot Info with Indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group