From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Subject: | Re: Way to check whether a particular block is on the shared_buffer? |
Date: | 2016-02-09 16:58:01 |
Message-ID: | CA+TgmoY7wx8sGTFhcffmqKBn4wzto8ZgUUNo8-35=6DXXRxQYg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Feb 7, 2016 at 9:49 PM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-02-09 17:13:01 | Re: Mac OS: invalid byte sequence for encoding "UTF8" |
Previous Message | Pavel Stehule | 2016-02-09 16:44:24 | Re: [patch] Proposal for \crosstabview in psql |