Re: Shared buffer access rule violations?

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

In response to

Responses

Browse pgsql-hackers by date

  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?