From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Asim R P <apraveen(at)pivotal(dot)io> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Shared buffer access rule violations? |
Date: | 2018-07-11 03:33:40 |
Message-ID: | 19346.1531280020@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Asim R P <apraveen(at)pivotal(dot)io> writes:
> In order to make changes to a shared buffer, one must hold a pin on it
> and the content lock in exclusive mode. This rule seems to be
> followed in most of the places but there are a few exceptions.
> One can find several PageInit() calls with no content lock held. See,
> for example:
> fill_seq_with_data()
That would be for a relation that no one else can even see yet, no?
> vm_readbuf()
> fsm_readbuf()
In these cases I'd imagine that the I/O completion interlock is what
is preventing other backends from accessing the buffer.
> Moreover, fsm_vacuum_page() performs
> "PageGetContents(page))->fp_next_slot = 0;" without content lock.
That field is just a hint, IIRC, and the possibility of a torn read
is explicitly not worried about.
> There may be more but I want to know if these can be treated as
> violations before moving ahead.
These specific things don't sound like bugs, though possibly I'm
missing something. Perhaps more comments would be in order.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-07-11 04:12:35 | Re: no partition pruning when partitioning using array type |
Previous Message | Michael Paquier | 2018-07-11 03:32:41 | Re: [HACKERS] WAL logging problem in 9.4.3? |