Re: Patch for fail-back without fresh backup

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Samrat Revagade <revagade(dot)samrat(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch for fail-back without fresh backup
Date: 2013-06-14 14:05:34
Message-ID: 51BB232E.3000305@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 14.06.2013 17:01, Andres Freund wrote:
> At this point we have a page that has been modified without an FPI. But
> it's not marked dirty, so it won't be written out without further
> cause. Which might be fine since there's no cause to write out the page
> and there probably won't be anyone doing that without logging an FPI
> independently.
> Can anybody see a scenario where this is actually dangerous?

The code also relies on that being safe during recovery:

> * If we're in recovery we cannot dirty a page because of a hint.
> * We can set the hint, just not dirty the page as a result so the
> * hint is lost when we evict the page or shutdown.
> *
> * See src/backend/storage/page/README for longer discussion.
> */
> if (RecoveryInProgress())
> return;

I can't immediately see a problem with that.

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2013-06-14 14:09:54 Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
Previous Message Andres Freund 2013-06-14 14:01:11 Re: Patch for fail-back without fresh backup