Re: pg_standby -l might destory the archived file

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_standby -l might destory the archived file
Date: 2009-06-02 18:54:21
Message-ID: 16657.1243968861@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> That's a good point; don't we recover files under names like
>> RECOVERYXLOG, not under names that could possibly conflict with regular
>> WAL files?

> Yes. But we rename RECOVERYXLOG to 000000010000000000000057 or similar
> at the end of recovery, in exitArchiveRecovery().

> Thinking about this some more, I think we should've changed
> exitArchiveRecovery() rather than RemoveOldXlogFiles(): it would be more
> robust if exitArchiveRecovery() always copied the last WAL file rather
> than just renamed it. It doesn't seem safe to rely on the file the
> symlink points to to be valid after recovery is finished, and we might
> write to it before it's recycled, so the current fix isn't complete.

Hmm. I think really the reason it's coded that way is that we assumed
the recovery command would be physically copying the file from someplace
else. pg_standby is violating the backend's expectations by using a
symlink. And I really doubt that the technique is saving anything, since
the data has to be read in from the archive location anyway.

I'm leaning back to the position that pg_standby's -l option is simply a
bad idea and should be removed.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Mielke 2009-06-02 19:17:01 Re: Managing multiple branches in git
Previous Message Bruce Momjian 2009-06-02 18:33:20 Re: [COMMITTERS] pgsql: Fix LOCK TABLE to eliminate the race condition that could make it