public inbox for [email protected]
help / color / mirror / Atom feedFrom: vinay kumar <[email protected]>
To: Laurenz Albe <[email protected]>
Cc: [email protected]
Subject: Re: Understanding recovery conflict due to bufferpin
Date: Wed, 24 Mar 2021 06:37:01 +0530
Message-ID: <CAMdzBEkRgQWxH8b7P6djqnhCVPvdNJVKj1FZfm+DqcXyaXC4HA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAMdzBEkg+EytT1XcsykcsarpLVu+oQcDV4ekdf6CMjOv8JpvyA@mail.gmail.com>
<[email protected]>
<CAMdzBE=2v6a61GWO+xHFbFX0rgAb1a+4fPxCK6Yi38x-wrDUSQ@mail.gmail.com>
<[email protected]>
Thanks for the clarification.
On Wed, Mar 24, 2021, 03:12 Laurenz Albe <[email protected]> wrote:
> On Tue, 2021-03-23 at 22:48 +0530, vinay kumar wrote:
> > My query is does the buffer pin pins block present in shared
> buffers(assuming the
> > block is already read into memory previously) or it's pinned to the
> block at the OS level?
> >
> > Also have another query:
> >
> > Do we have any queue mechanism to attain buffer pins on a block?
> >
> > To provide an example:
> >
> > Let's say, I need to read tuples present in a block by multiple backends.
> > Shouldn't the backends wait in FIFO order to hold pins on the block?
> >
> > To give you an example, if I have the few backends requesting access to
> a block
> > in the following order:
> >
> > -> backend 1: reads the tuples from block
> > -> backend 2: reads the tuples from block
> > -> backend 3: reads the tuples from block
> > -> WAL replay: waiting to modify block either due to replaying change or
> Vacuum operation.
> >
> > Will the order of requests to access blocks be maintained in a cache or
> any other memory area?
> >
> > If possible to implement lazy cache invalidation (invalidating blocks in
> buffer cache
> > when no conflicts query is run), it would be great and helpful to lots
> of users who query
> > data from standby to avoid recovery conflict and don't have to re-run
> the entire query once
> > again consuming resources.
>
> A pin is not a lock, it just protects a page from being swapped out of
> cache.
> Several backends can pin the same page simultaneously.
>
> The buffer pin is an internal PostgreSLQ concept and has nothing to do
> with the operating system.
>
> I recommend that you start by reading the appropriate README:
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/storage/buffer/README
> That explains the concepts better than I could.
>
> The key sentence when it comes to replication conflicts is this:
>
> To physically remove a tuple or compact free space on a page, one
> must hold a pin and an exclusive lock, *and* observe while holding the
> exclusive lock that the buffer's shared reference count is one (ie,
> no other backend holds a pin).
>
> Yours,
> Laurenz Albe
> --
> Cybertec | https://www.cybertec-postgresql.com
>
>
view thread (5+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Understanding recovery conflict due to bufferpin
In-Reply-To: <CAMdzBEkRgQWxH8b7P6djqnhCVPvdNJVKj1FZfm+DqcXyaXC4HA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox