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: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>,"Jacky Leng" <lengjianquan(at)163(dot)com>,"Patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Why copy_relation_data only use wal whenWALarchivingis enabled
Date: 2007-10-18 21:13:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
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

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

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2007-10-18 21:35:08
Subject: Re: I've discovered an error with the tcl pgmail function
Previous:From: Merlin MoncureDate: 2007-10-18 20:33:06
Subject: Re: Proposal: generate_iterator functions

pgsql-patches by date

Next:From: Jorge GodoyDate: 2007-10-18 23:02:54
Subject: Re: Crosstab Problems
Previous:From: Joe ConwayDate: 2007-10-18 18:37:59
Subject: Re: Crosstab Problems

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