Re: [HACKERS] [PATCHES] Fix mdsync never-ending loop problem

2007-04-12 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > I believe Itagaki-san's motivation for tackling this in the LDC patch > was the fact that it can fsync the same file many times, and in the > worst case go to an endless loop, and adding delays inside the loop > makes it much more likely. After th

Re: [HACKERS] [PATCHES] Fix mdsync never-ending loop problem

2007-04-12 Thread Heikki Linnakangas
Tom Lane wrote: 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

Re: [HACKERS] [PATCHES] Fix mdsync never-ending loop problem

2007-04-12 Thread Tom Lane
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 us

Re: [HACKERS] [PATCHES] Fix mdsync never-ending loop problem

2007-04-12 Thread Heikki Linnakangas
Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: My first thought is that the cycle_ctr just adds extra complexity. The canceled-flag really is the key in Takahiro-san's patch, so we don't need the cycle_ctr anymore. We don't have to have it in the sense of the code not working

Re: [HACKERS] [PATCHES] Fix mdsync never-ending loop problem

2007-04-11 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > My first thought is that the cycle_ctr just adds extra complexity. The > canceled-flag really is the key in Takahiro-san's patch, so we don't > need the cycle_ctr anymore. We don't have to have it in the sense of the code not working without it, b

Re: [HACKERS] [PATCHES] Fix mdsync never-ending loop problem

2007-04-11 Thread Heikki Linnakangas
Tom Lane wrote: I wrote: Actually, on second look I think the key idea here is Takahiro-san's introduction of a cancellation flag in the hashtable entries, to replace the cases where AbsorbFsyncRequests can try to delete entries. What that means is mdsync() doesn't need an outer retry loop at al

Re: [HACKERS] [PATCHES] Fix mdsync never-ending loop problem

2007-04-10 Thread Tom Lane
I wrote: > I fooled around with this idea and came up with the attached patch. > It seems to do what's intended but could do with more eyeballs and > testing before committing. Comments please? Earlier I said that I didn't want to back-patch this change, but on looking at the CVS history I'm reco

Re: [HACKERS] [PATCHES] Fix mdsync never-ending loop problem

2007-04-10 Thread Tom Lane
I wrote: > Actually, on second look I think the key idea here is Takahiro-san's > introduction of a cancellation flag in the hashtable entries, to > replace the cases where AbsorbFsyncRequests can try to delete entries. > What that means is mdsync() doesn't need an outer retry loop at all: I foole

Re: [HACKERS] [PATCHES] Fix mdsync never-ending loop problem

2007-04-10 Thread Tom Lane
I wrote: > This patch looks fairly sane to me; I have a few small gripes about > coding style but that can be fixed while applying. Heikki, you were > concerned about the cycle-ID idea; do you have any objection to this > patch? Actually, on second look I think the key idea here is Takahiro-san's