Re: unsafe use of hash_search(... HASH_ENTER ...)
От | Qingqing Zhou |
---|---|
Тема | Re: unsafe use of hash_search(... HASH_ENTER ...) |
Дата | |
Msg-id | d768t0$1d9c$1@news.hub.org обсуждение исходный текст |
Ответ на | unsafe use of hash_search(... HASH_ENTER ...) ("Qingqing Zhou" <zhouqq@cs.toronto.edu>) |
Ответы |
Re: unsafe use of hash_search(... HASH_ENTER ...)
|
Список | pgsql-hackers |
"Tom Lane" <tgl@sss.pgh.pa.us> writes > "Qingqing Zhou" <zhouqq@cs.toronto.edu> writes: > > "Unsafe" is a bit of an overstatement, when you evidently haven't > analyzed the consequences of either choice of error level. That is, > why is this a bug? > Consider the senario like this: Backends register some dirty segments in BgWriterShmem->requests; bgwrite will AbsorbFsyncRequests() asynchornously but failed to record some one in pendingOpsTable due to an "out of memory" error. All dirty segments remembered in "requests" after this one will not have chance be absorbed by bgwriter. Recall we have already removed those dirty segment by: BgWriterShmem->num_requests = 0; So we will have no chance to pick up it again. That is, we will never fsync some dirty segments (mdwrite() will not sync those files themselves either because ForwardFsyncRequest() is successfully done). Regards, Qingqing
В списке pgsql-hackers по дате отправления: