Re: Way to check whether a particular block is on the shared_buffer?
От | Robert Haas |
---|---|
Тема | Re: Way to check whether a particular block is on the shared_buffer? |
Дата | |
Msg-id | CA+TgmoY7wx8sGTFhcffmqKBn4wzto8ZgUUNo8-35=6DXXRxQYg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Way to check whether a particular block is on the shared_buffer? (Kouhei Kaigai <kaigai@ak.jp.nec.com>) |
Список | pgsql-hackers |
On Sun, Feb 7, 2016 at 9:49 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote: > On the other hands, it also became clear we have to guarantee OS buffer > or storage block must not be updated partially during the P2P DMA. > My motivation is a potential utilization of P2P DMA of SSD-to-GPU to > filter out unnecessary rows and columns prior to loading to CPU/RAM. > It needs to ensure PostgreSQL does not write out buffers to OS buffers > to avoid unexpected data corruption. > > What I want to achieve is suspend of buffer write towards a particular > (relnode, forknum, blocknum) pair for a short time, by completion of > data processing by GPU (or other external devices). > In addition, it is preferable being workable regardless of the choice > of storage manager, even if we may have multiple options on top of the > pluggable smgr in the future. It seems like you just need to take an exclusive content lock on the buffer, or maybe a shared content lock would be sufficient. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: