From: | Asim R P <apraveen(at)pivotal(dot)io> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Shared buffer access rule violations? |
Date: | 2018-07-11 18:31:22 |
Message-ID: | CANXE4Tfu30j6bXS96gh5VCCdecPv6a6Y=GLATHV==kaifDz7JA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 10, 2018 at 8:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Asim R P <apraveen(at)pivotal(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Nico Williams | 2018-07-11 18:41:12 | Re: [HACKERS] [PATCH] WIP Add ALWAYS DEFERRED option for constraints |
Previous Message | Pavel Raiskup | 2018-07-11 18:24:59 | Re: [PATCH] btree_gist: fix union implementation for variable length columns |