Heikki Linnakangas <heikki@enterprisedb.com> writes:
> Ok. Perhaps we should not use the canceled-flag but just remove the
> entry from pendingOpsTable like we used to when mdsync_in_progress isn't
> set.
I'm not thrilled about that; it seems overly intricate, and won't the
LDC patch make it mostly useless anyway (because of time-extended
checkpointing)?
> I think there's one little bug in the patch:
> 1. AbsorbFsyncRequests is called. A FORGET message is received, and an
> entry in the hash table is marked as canceled
> 2. Another relation with the same relfilenode is created. This can
> happen after OID wrap-around
> 3. RememberFsyncRequest is called for the new relation. The old entry is
> still in the hash table, marked with the canceled-flag, so it's not touched.
Good point. I was wondering what to do with an already-canceled entry,
but didn't think of that scenario. I think your fix is not quite right:
if we clear a pre-existing cancel flag then we do need to set cycle_ctr,
because this is effectively an all-new request.
regards, tom lane
