Re: Shared buffer access rule violations?

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Asim R P <apraveen@pivotal.io>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2018-07-11T03:33:40Z
Lists: pgsql-hackers
Asim R P <apraveen@pivotal.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


Commits

  1. Fix inadequate buffer locking in FSM and VM page re-initialization.