(Sorry if you receive duplicate messages. I resend it since it was not
delivered after a day.)
Here is another patch to fix never-ending loop in mdsync. I introduced
a mdsync counter (cycle id) and cancel flags to fix the problem.
The mdsync counter is incremented at the every beginning of mdsync().
Each pending entry has a field assigned from the counter when it is
newly inserted to pendingOpsTable. Only entries that have smaller counter
values than the mdsync counter are fsync-ed in mdsync().
Another change is to add a cancel flag in each pending entry. When a
relation is dropped and bgwriter receives a forget-request, the corresponding
entry is marked as dropped but we don't delete it at that time. Actual
deletion is performed in the next fsync loop. We don't have to retry after
AbsorbFsyncRequests() because entries are not removed outside of seqscan.
This patch can be applied to HEAD, 8.2 and 8.1 with a few hunks.
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > In my understanding from the discussion, we'd better to take "cycle ID"
> > approach instead of "making a copy of pendingOpsTable", because duplicated
> > table is hard to debug and requires us to pay attention not to leak memories.
> > I'll adopt the cycle ID approach and build LDC on it as a separate patch.
>
> Heikki made some reasonable arguments against the cycle-ID idea. I'm
> not intending to insist on it ...
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center