From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Ants Aasma <ants(at)cybertec(dot)at> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Andres Freund <andres(at)2ndquadrant(dot)com>, Дмитрий Дегтярёв <degtyaryov(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PERFORM] Cpu usage 100% on slave. s_lock problem. |
Date: | 2013-10-02 19:37:50 |
Message-ID: | CAHyXU0xUw0qwYCe1Fm43=Afh5iNk63BVpS4vAhjxZn9upQ-XjQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 2, 2013 at 9:45 AM, Ants Aasma <ants(at)cybertec(dot)at> wrote:
> I haven't reviewed the code in as much detail to say if there is an
> actual race here, I tend to think there's probably not, but the
> specific pattern that I had in mind is that with the following actual
> code:
hm. I think there *is* a race. 2+ threads could race to the line:
LocalRecoveryInProgress = xlogctl->SharedRecoveryInProgress;
and simultaneously set the value of LocalRecoveryInProgress to false,
and both engage InitXLOGAccess, which is destructive. The move
operation is atomic, but I don't think there's any guarantee the reads
to xlogctl->SharedRecoveryInProgress are ordered between threads
without a lock.
I don't think the memory barrier will fix this. Do you agree? If so,
my earlier patch (recovery4) is another take on this problem, and
arguable safer; the unlocked read is in a separate path that does not
engage InitXLOGAccess()
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2013-10-02 20:04:19 | Re: [PATCH] pg_upgrade: support for btrfs copy-on-write clones |
Previous Message | Andrew Gierth | 2013-10-02 17:45:24 | Re: [HACKERS] Who is pgFoundery administrator? |