Re: [HACKERS] Fix mdsync never-ending loop problem
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Fix mdsync never-ending loop problem |
Дата | |
Msg-id | 19188.1176384592@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Fix mdsync never-ending loop problem (Heikki Linnakangas <heikki@enterprisedb.com>) |
Ответы |
Re: [HACKERS] Fix mdsync never-ending loop problem
|
Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления: