Re: Shared buffer access rule violations?
P <apraveen@pivotal.io>
From: Asim R P <apraveen@pivotal.io>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2018-07-11T18:31:22Z
Lists: pgsql-hackers
On Tue, Jul 10, 2018 at 8:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Asim R P <apraveen@pivotal.io> writes: > >> 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? Yes, when the sequence is being created. No, when the sequence is being reset, in ResetSequence(). > >> 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. > What is I/O completion interlock? I see no difference in initializing a visimap/fsm page and initializing a standard heap page. For standard heap pages, the code currently acquires the buffer pin as well as content lock for initialization. >> 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. Yes, that's a hint. And ignoring torn page possibility doesn't result in checksum failures because fsm_read() passes RMB_ZERO_ON_ERROR to buffer manager. The page will be zeroed out in the event of checksum failure. Asim
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