Re: BUG #4879: bgwriter fails to fsync the file in recovery mode

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>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Date: 2009-06-25 20:46:23
Message-ID: 4977.1245962783@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> I would like an explanation of why minimum recovery point needs to
>> be advanced at all. If there's any use for it, it is surely part
>> of functionality that is not there in 8.4.

> It gives protection against starting up the database too early.

Protection against what failure scenario?

> It stops
> the database from starting up if you stop recovery, and move recovery
> target backwards or delete WAL files from pg_xlog, in a way that's not
> safe. Of course, that's a case of "don't do that!", but it's a mistake
> you can make when trying to manually recover to a given point in time.

You can't move the target backwards --- it's embedded in pg_control.
And even if you could, I don't see what protection this particular
mechanism gives you. To the extent that it does anything at all, it's
going to be full of holes because it only examines pages that happen to
be dirtied by (the current instance of) the recovery process.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Heikki Linnakangas 2009-06-25 20:59:39 Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Previous Message Simon Riggs 2009-06-25 20:39:06 Re: BUG #4879: bgwriter fails to fsync the file in recovery mode