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
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 |