Re: [HACKERS] Fix mdsync never-ending loop problem
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] Fix mdsync never-ending loop problem |
| Дата | |
| Msg-id | 22503.1176392540@sss.pgh.pa.us обсуждение |
| Ответ на | Re: [HACKERS] Fix mdsync never-ending loop problem (Heikki Linnakangas <heikki@enterprisedb.com>) |
| Список | pgsql-patches |
Heikki Linnakangas <heikki@enterprisedb.com> 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 that is fixed, I doubt any of the
> optimizations of trying to avoid extra fsyncs make any difference in
> real applications, and we should just keep it simple, especially if we
> back-patch it.
I looked at the dynahash code and noticed that new entries are attached
to the *end* of their hashtable chain. While this maybe should be
changed to link them at the front, the implication at the moment is that
without a cycle counter it would still be possible to loop indefinitely
because we'd continue to revisit the same file(s) after removing their
hashtable entries. I think you'd need a constant stream of requests for
more than one file falling into the same hash chain, but it certainly
seems like a potential risk. I'd prefer a solution that adheres to the
dynahash API's statement that it's unspecified whether newly-added
entries will be visited by hash_seq_search, and will in fact not loop
even if they always are visited.
> That said, I'm getting tired of this piece of code :).
Me too.
regards, tom lane
В списке pgsql-patches по дате отправления: