| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Hot Standby 0.2.1 |
| Date: | 2009-09-27 11:59:27 |
| Message-ID: | 4ABF539F.8050305@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
The locking in smgr_redo_commit and smgr_redo_abort doesn't look right.
First of all, smgr_redo_abort is not holding XidGenLock and
ProcArrayLock while modifying ShmemVariableCache->nextXid and
ShmemVariableCache->latestCompletedXid, respectively, like
smgr_redo_commit is. Attached patch fixes that.
But I think there's a little race condition in there anyway, as they
remove the finished xids from known-assigned-xids list by calling
ExpireTreeKnownAssignedTransactionIds, and
ShmemVariableCache->latestCompletedXid is updated only after that. We're
not holding ProcArrayLock between those two steps, like we do during
normal transaction commit. I'm not sure what kind of issues that can
lead to, but it seems like it can lead to broken snapshots if someone
calls GetSnapshotData() between those steps.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Make-locking-in-smgr_redo_abort-reflect-that-in-smgr.patch | text/x-diff | 0 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2009-09-27 12:35:08 | Re: Hot Standby 0.2.1 |
| Previous Message | Jim Cox | 2009-09-27 11:32:41 | Re: [PATCH] 8.5 TODO: Add comments to output indicating version of pg_dump and of the database server |