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
-
Fix inadequate buffer locking in FSM and VM page re-initialization.
- 0cf3363c0110 9.3.24 landed
- 6d2d5ab173a9 9.4.19 landed
- 17c3dabbb70c 9.5.14 landed
- 073ffefd8082 9.6.10 landed
- f1963a1e79a4 10.5 landed
- 5586e42b3493 11.0 landed
- 130beba36d6d 12.0 landed