Re: Race condition between hot standby and restoring a FPW

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Race condition between hot standby and restoring a FPW
Date: 2014-11-12 15:29:42
Message-ID: 54637CE6.7080207@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/12/2014 05:20 PM, Tom Lane wrote:
> Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
>> On 11/12/2014 04:56 PM, Tom Lane wrote:
>>> Not great either. What about an RBM_NOERROR mode that is like RBM_ZERO
>>> in terms of handling error conditions, but does not forcibly zero the page
>>> if it's already valid?
>
>> Anyway, you don't want to read the page from disk, just to check if it's
>> already valid.
>
> Oh, good point.
>
>> (Note that when the page is already in the buffer-cache, RBM_ZERO
>> already doesn't zero the page. So this race condition only happens when
>> the page isn't in the buffer cache yet).
>
> Right.
>
> On reconsideration I think the "RBM_ZERO returns page already locked"
> alternative may be the less ugly. That has the advantage that any code
> that doesn't get updated will fail clearly and reliably.

Yeah, I'm leaning to that approach as well. It's made more ugly by the
fact that you sometimes need a cleanup lock on the buffer, so the caller
will somehow need to specify whether to get a cleanup lock or a normal
exclusive lock. Maybe add yet another mode, RBM_ZERO_WITH_CLEANUP_LOCK.
Could also rename RBM_ZERO to e.g. RBM_ZERO_AND_LOCK, to make any code
that's not updated to break even more obviously, at compile-time.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-11-12 15:47:34 Re: Race condition between hot standby and restoring a FPW
Previous Message Heikki Linnakangas 2014-11-12 15:24:29 Re: Race condition between hot standby and restoring a FPW