Date: Tue, 2 Aug 2016 01:49:09 -0400
From: Noah Misch <noah@leadboat.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>,
	Masahiko Sawada <sawada.mshk@gmail.com>,
	Alvaro Herrera <alvherre@2ndquadrant.com>,
	Robert Haas <robertmhaas@gmail.com>,
	Thomas Munro <thomas.munro@enterprisedb.com>,
	Stephen Frost <sfrost@snowman.net>,
	Michael Paquier <michael.paquier@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Reviewing freeze map code
Message-ID: <20160802054909.GA2308967@tornado.leadboat.com>
References: <20160716013203.gni5x6jjnmjajvc6@alap3.anarazel.de>
 <CAA4eK1K_-Q8KkFykNn0dAhs2=MM2=Sj6n7oz+HtTsdXgjZKGpg@mail.gmail.com>
 <25549.1468684146@sss.pgh.pa.us>
 <2E9AE050-767F-40E8-8F09-66BA64E67DE3@anarazel.de>
 <20160718024829.s3mucbxipk2r4jvp@alap3.anarazel.de>
 <CAA4eK1LM+X37D8mMwNZDfG-_JjxNtzc0T+VjBPCxWiFRgWuZPg@mail.gmail.com>
 <20160718034352.ddzljwmmsicprknj@alap3.anarazel.de>
 <CAA4eK1JbueL-8pmUTMD6dCRUcC0nZwHpEsVoj9ETCmjKZgf_KQ@mail.gmail.com>
 <20160718083310.jyshh2s4t2xnurka@alap3.anarazel.de>
 <CAA4eK1+O+=TZ2eyEQoN1JOMS+K2T1Tga=1bnaH08OFfJwUH9mg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAA4eK1+O+=TZ2eyEQoN1JOMS+K2T1Tga=1bnaH08OFfJwUH9mg@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On Sat, Jul 23, 2016 at 01:25:55PM +0530, Amit Kapila wrote:
> On Mon, Jul 18, 2016 at 2:03 PM, Andres Freund <andres@anarazel.de> wrote:
> > On 2016-07-18 10:02:52 +0530, Amit Kapila wrote:
> >> Consider the below scenario.
> >>
> >> Vacuum
> >> a. acquires a cleanup lock for page - 10
> >> b. busy in checking visibility of tuples
> >> --assume, here it takes some time and in the meantime Session-1
> >> performs step (a) and (b) and start waiting in step- (c)
> >> c. marks the page as all-visible (PageSetAllVisible)
> >> d. unlockandrelease the buffer
> >>
> >> Session-1
> >> a. In heap_lock_tuple(), readbuffer for page-10
> >> b. check PageIsAllVisible(), found page is not all-visible, so didn't
> >> acquire the visbilitymap_pin
> >> c. LockBuffer in ExlusiveMode  - here it will wait for vacuum to
> >> release the lock
> >> d. Got the lock, but now the page is marked as all-visible, so ideally
> >> need to recheck the page and acquire the visibilitymap_pin
> >
> > So, I've tried pretty hard to reproduce that. While the theory above is
> > sound, I believe the relevant code-path is essentially dead for SQL
> > callable code, because we'll always hold a buffer pin before even
> > entering heap_update/heap_lock_tuple.
> >
> 
> It is possible that we don't hold any buffer pin before entering
> heap_update() and or heap_lock_tuple().  For heap_update(), it is
> possible when it enters via simple_heap_update() path.  For
> heap_lock_tuple(), it is possible for ON CONFLICT DO Update statement
> and may be others as well.

This is currently listed as a 9.6 open item.  Is it indeed a regression in
9.6, or do released versions have the same defect?  If it is a 9.6 regression,
do you happen to know which commit, or at least which feature, caused it?

Thanks,
nm


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers