| 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-14 03:07:06 |
| Message-ID: | CA+TgmoYBxonJvK8sGSmC9PK+17ou=gL9Gje6A+wdhw+rPNRdoQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Feb 13, 2016 at 7:29 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
>> I suppose there's no theoretical reason why the buffer couldn't go
>> from all-visible to not-all-visible and back to all-visible again all
>> during the time you are copying it.
>>
> The backend process that is copying the data to GPU has a transaction
> in-progress (= not committed). Is it possible to get the updated buffer
> page back to the all-visible state again?
> I expect that in-progress transactions works as a blocker for backing
> to all-visible. Right?
Yeah, probably.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2016-02-14 03:28:53 | Re: proposal: function parse_ident |
| Previous Message | Robert Haas | 2016-02-14 03:01:51 | Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl |