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

Re: Re: [COMMITTERS] pgsql: Make standby servercontinuously retry restoring the next WAL

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
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: Re: [COMMITTERS] pgsql: Make standby servercontinuously retry restoring the next WAL
Date: 2010-02-11 14:42:04
Message-ID: 20100211144204.GC14128@oak.highrise.ca (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-docspgsql-hackers
* Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> [100211 09:17]:

> If the file is just being copied to the archive when restore_command
> ('cp', say) is launched, it will copy a half file. That's not a problem
> for PITR, because PITR will end at the end of valid WAL anyway, but
> returning a half WAL file in standby mode is a problem.

But it can be a problem - without the last WAL (or at least enough of
it) the master switched and archived, you have no guarantee of having
being consistent again (I'm thinking specifically of recovering from a
fresh backup)

> Yeah, if you're careful about that, then this change isn't required. But
> pg_standby protects against that, so I think it'd be reasonable to have
> the same level of protection built-in. It's not a lot of code.

This 1 check isn't, but what about the rest of the things pg_standby
does.  How much functionality should we bring it?  Ideally, "all" of it.

> We could well just document that you should do that, ie. make sure the
> file appears in the archive atomically with the right size.

I have to admit, today was the first time I went and re-read the PITR
docs, and no, the docs don't seem to talk about that... Maybe it was
just plain obvious to me because it (the atomic apperance) is something
unix devloppers have always had to deal with, so it's ingrained in me.
But I'm *sure* that I've seen that bandied around as common knowledge on
the lists, and one of the reasons we alway see warnings about using
rsync instead of plain SCP, etc.

So ya, we should probably mention that somewhere in the docs.  Section
24.3.6. Caveats?

a.

-- 
Aidan Van Dyk                                             Create like a god,
aidan(at)highrise(dot)ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

In response to

Responses

pgsql-docs by date

Next:From: Greg SmithDate: 2010-02-11 14:55:11
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous:From: Simon RiggsDate: 2010-02-11 14:38:40
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

pgsql-hackers by date

Next:From: Greg StarkDate: 2010-02-11 14:51:46
Subject: Re: knngist patch support
Previous:From: Koichi SuzukiDate: 2010-02-11 14:39:13
Subject: Bug on pg_lesslog

pgsql-committers by date

Next:From: Greg SmithDate: 2010-02-11 14:55:11
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous:From: Simon RiggsDate: 2010-02-11 14:38:40
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

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