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-24 10:33:30 |
Message-ID: | 4ABB4AFA.4090605@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> The problem becomes a lot easier if we accept that it's OK to have a
> lock included in the running-xacts snapshot and also appear in a
> XLOG_RELATION_LOCK record later. The standby should handle that
> gracefully already. If we just remove RecoveryInfoLock, that can happen,
> but it still won't be possible for a lock to be missed out which is what
> we really care about.
I see the problem with that now. Without the lock, it's possible that
the XLOG_RELATION_LOCK WAL record is written before the
XLOG_RUNNING_XACTS record. If the lock is not included in the snapshot,
we want the lock WAL record to be after the snapshot record.
So i guess we'll need the RecoveryInfoLock. But we don't need to hold it
across the wait. I think it's enough to acquire it just before writing
the WAL record in LockAcquire. That will ensure that the WAL record
isn't written until the snapshot is completely finished.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2009-09-24 10:41:57 | Re: Streaming Replication patch for CommitFest 2009-09 |
Previous Message | Fujii Masao | 2009-09-24 10:25:02 | Re: Streaming Replication patch for CommitFest 2009-09 |