Re: Re: [COMMITTERS] pgsql: Make standby server continuously 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 server continuously retry restoring the next WAL
Date: 2010-02-11 14:42:04
Message-ID: 20100211144204.GC14128@oak.highrise.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-docs pgsql-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

Browse pgsql-committers by date

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

Browse pgsql-docs by date

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

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2010-02-11 14:51:46 Re: knngist patch support
Previous Message Koichi Suzuki 2010-02-11 14:39:13 Bug on pg_lesslog