On Tue, Aug 02, 2016 at 02:10:29PM +0530, Amit Kapila wrote: > On Tue, Aug 2, 2016 at 11:19 AM, Noah Misch <n...@leadboat.com> wrote: > > On Sat, Jul 23, 2016 at 01:25:55PM +0530, Amit Kapila wrote: > >> On Mon, Jul 18, 2016 at 2:03 PM, Andres Freund <and...@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? > > > > Commit eca0f1db is the reason for this specific issue.
[Action required within 72 hours. This is a generic notification.] The above-described topic is currently a PostgreSQL 9.6 open item. Andres, since you committed the patch believed to have created it, you own this open item. If some other commit is more relevant or if this does not belong as a 9.6 open item, please let us know. Otherwise, please observe the policy on open item ownership[1] and send a status update within 72 hours of this message. Include a date for your subsequent status update. Testers may discover new open items at any time, and I want to plan to get them all fixed in advance of shipping 9.6rc1 next week. Consequently, I will appreciate your efforts toward speedy resolution. Thanks. [1] http://www.postgresql.org/message-id/20160527025039.ga447...@tornado.leadboat.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
