Heikki Linnakangas <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to