Re: Move tablespace

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Move tablespace
Date: 2010-04-21 12:01:45
Message-ID: 1271851305.8305.27737.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2010-04-21 at 14:37 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Tue, 2010-04-20 at 21:03 -0400, Tom Lane wrote:
> >> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> >>> Following patch writes a new WAL record that just says "copy foo to
> >>> newts" and during replay we flush buffers and then re-execute the copy
> >>> (but only when InArchiveRecovery). So the copy happens locally on the
> >>> standby, not copying from primary to standby. We do this just with a
> >>> little refactoring and a simple new WAL message.
> >> And what happens to crash-recovery replay? You can't have it both ways,
> >> either the data is in WAL or it's missing.
> >
> > The patch changes nothing in the case of crash recovery.
>
> What happens if the record is replayed twice in archive recovery? For
> example if you stop and restart a standby server after it has replayed
> that record. What does the 2nd redo attempt do if the source file was
> already deleted by the 1st recovery.

If the source is absent then we know that replay had successfully copied
the file and synced it, so we can just skip the record.

> I also think we shouldn't be fiddling with this at this stage in the
> release cycle.

OK, but not because I see a problem with the technique.

--
Simon Riggs www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-04-21 12:05:38 Re: BETA
Previous Message Heikki Linnakangas 2010-04-21 11:37:57 Re: Move tablespace