From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Report: race conditions in WAL replay routines |
Date: | 2012-02-05 22:23:18 |
Message-ID: | 22343.1328480598@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> Please post the patch rather than fixing directly. There's some subtle
> stuff there and it would be best to discuss first.
Here's a proposed patch for the issues around unlocked updates of
shared-memory state. After going through this I believe that there is
little risk of any real problems in the current state of the code; this
is more in the nature of future-proofing against foreseeable changes.
(One such is that we'd discussed fixing the age() function to work
during Hot Standby.) So I suggest applying this to HEAD but not
back-patching.
Except for one thing. I realized while looking at the NEXTOID replay
code that it is completely broken: it only advances
ShmemVariableCache->nextOid when that's less than the value in the WAL
record. So that comparison fails if the OID counter wraps around during
replay. I've fixed this in the attached patch by just forcibly
assigning the new value instead of trying to be smart, and I think
probably that aspect of it needs to be back-patched.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
shmemvariablecache-replay.patch | text/x-patch | 12.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2012-02-05 22:56:57 | Re: initdb and fsync |
Previous Message | Simon Riggs | 2012-02-05 21:29:20 | Re: Report: race conditions in WAL replay routines |