Re: [HACKERS] Possible duplicate release of buffer lock.

Hello, At Sat, 06 Aug 2016 12:45:32 -0400, Tom Lane wrote in <16748.1470501...@sss.pgh.pa.us> > Amit Kapila writes: > > Isn't the problem here is that due to some reason (like concurrent > > split), the code in question (loop -- > > while

Re: [HACKERS] Possible duplicate release of buffer lock.

Amit Kapila writes: > Isn't the problem here is that due to some reason (like concurrent > split), the code in question (loop -- > while (P_ISDELETED(opaque) || opaque->btpo_next != target)) releases > the lock on target buffer and the caller again tries to release the >

Re: [HACKERS] Possible duplicate release of buffer lock.

On Fri, Aug 5, 2016 at 11:27 AM, Kyotaro HORIGUCHI wrote: > Hello, > > If concurrent deletion (marking half-dead, specifically) can't > happen, P_ISDELETED() won't be seen in the loop but we may > consider it as a skippable condition to continue VACUUM. But >

Re: [HACKERS] Possible duplicate release of buffer lock.

Hello, At Thu, 4 Aug 2016 16:09:17 -0700, Peter Geoghegan wrote in > On Wed, Aug 3, 2016 at 1:31 AM, Kyotaro HORIGUCHI > wrote: > > The first line is emitted for simultaneous

Re: [HACKERS] Possible duplicate release of buffer lock.

At Wed, 03 Aug 2016 12:00:33 -0400, Tom Lane wrote in <26373.1470240...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > My point here is that if concurrent deletion can't be perfomed by > > the current implement, this while loop could be

Re: [HACKERS] Possible duplicate release of buffer lock.

On Wed, Aug 3, 2016 at 1:31 AM, Kyotaro HORIGUCHI wrote: > The first line is emitted for simultaneous deletion of a index > page, which is impossible by design in a consistent state so the > complained situation should be the result of an index corruption > before

Re: [HACKERS] Possible duplicate release of buffer lock.

Sorry. That's partially wrong. At Wed, 03 Aug 2016 17:31:16 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20160803.173116.111915228.horiguchi.kyot...@lab.ntt.co.jp> > I had an inquiry about the following log messages. > > 2016-07-20 10:16:58.294

Re: [HACKERS] Possible duplicate release of buffer lock.

Kyotaro HORIGUCHI writes: > My point here is that if concurrent deletion can't be perfomed by > the current implement, this while loop could be removed and > immediately error out or log a message, >> if (P_ISDELETED(opaque) || opaque->btpo_next != target) >> {

[HACKERS] Possible duplicate release of buffer lock.

Hello, I had an inquiry about the following log messages. 2016-07-20 10:16:58.294 JST,,,3240,,578ed102.ca8,1,,2016-07-20 10:16:50 JST,30/75,0,LOG,0,"no left sibling (concurrent deletion?) in ""some_index_rel""""_bt_unlink_halfdead_page, nbtpage.c:1643","" 2016-07-20 10:16:58.294