Re: [HACKERS] Assertion failure in REL9_5_STABLE

2017-04-28 Thread Pavan Deolasee 
On Wed, Apr 19, 2017 at 11:19 AM, Andrew Gierth  wrote:

> > "Pavan" == Pavan Deolasee  writes:
>
>  Pavan> I am attaching a patch that throws a similar ERROR during
>  Pavan> planning even for 9.5. AFAICS in presence of grouping sets, we
>  Pavan> always decide to use sort-based implementation for grouping, but
>  Pavan> do not check if the columns support ordering or not.
>
> Hmmm. This is obviously my fault somewhere... the patch looks good, I'll
> deal with it shortly.
>

JFR this got fixed via 7be3678a8cfb55dcfca90fa586485f835ab912a5

Thanks,
Pavan

-- 
 Pavan Deolasee   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2017-04-18 Thread Pavan Deolasee 
On Wed, Apr 19, 2017 at 11:19 AM, Andrew Gierth  wrote:

> > "Pavan" == Pavan Deolasee  writes:
>
>  Pavan> I am attaching a patch that throws a similar ERROR during
>  Pavan> planning even for 9.5. AFAICS in presence of grouping sets, we
>  Pavan> always decide to use sort-based implementation for grouping, but
>  Pavan> do not check if the columns support ordering or not.
>
> Hmmm. This is obviously my fault somewhere... the patch looks good, I'll
> deal with it shortly.
>
>
Thanks. It might be a good idea to include that test case from the master.
Please let me know if you would like me to send a new patch which includes
that.

Thanks,
Pavan

-- 
 Pavan Deolasee   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2017-04-18 Thread Andrew Gierth 
> "Pavan" == Pavan Deolasee  writes:

 Pavan> I am attaching a patch that throws a similar ERROR during
 Pavan> planning even for 9.5. AFAICS in presence of grouping sets, we
 Pavan> always decide to use sort-based implementation for grouping, but
 Pavan> do not check if the columns support ordering or not.

Hmmm. This is obviously my fault somewhere... the patch looks good, I'll
deal with it shortly.

-- 
Andrew (irc:RhodiumToad)


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

[HACKERS] Assertion failure in REL9_5_STABLE

2017-04-18 Thread Pavan Deolasee 
Hi All,

I stumbled upon this test case from the master that sets an assertion
failure (see stack trace at the end) on REL9_5_STABLE.

create temp table gstest4(id integer, v integer,
  unhashable_col bit(4), unsortable_col xid);
insert into gstest4
values (1,1,b'','1'), (2,2,b'0001','1'),
   (3,4,b'0010','2'), (4,8,b'0011','2'),
   (5,16,b'','2'), (6,32,b'0001','2'),
   (7,64,b'0010','1'), (8,128,b'0011','1');

-- mixed hashable/sortable cases
select unhashable_col, unsortable_col,
   grouping(unhashable_col, unsortable_col),
   count(*), sum(v)
  from gstest4 group by grouping sets ((unhashable_col),(unsortable_col))
 order by 3, 5;

I tested this with REL9_6_STABLE and it throws a more useful error message,
presumably because the code was refactored quite heavily for upper planner
changes.

ERROR:  could not implement GROUP BY
DETAIL:  Some of the datatypes only support hashing, while others only
support sorting.

I am attaching a patch that throws a similar ERROR during planning even for
9.5. AFAICS in presence of grouping sets, we always decide to use
sort-based implementation for grouping, but do not check if the columns
support ordering or not.

I did not test it for other older branches because grouping sets were
introduced in 9.5.

Thanks,
Pavan


(lldb) bt
* thread #1: tid = 0x, 0x7fff9c1dfdda
libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGSTOP
  * frame #0: 0x7fff9c1dfdda libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x7fff9c2cb787 libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x7fff9c145420 libsystem_c.dylib`abort + 129
frame #3: 0x00010f61a3f0
postgres`ExceptionalCondition(conditionName="!(sortOperators[i] != 0)",
errorType="BadArgument", fileName="tuplesort.c", lineNumber=657) + 128 at
assert.c:54
frame #4: 0x00010f65a07d
postgres`tuplesort_begin_heap(tupDesc=0x7fb1528194d8, nkeys=1,
attNums=0x7fb15280e9e0, sortOperators=0x7fb15280ea00,
sortCollations=0x7fb15280ea20, nullsFirstFlags="", workMem=4096,
randomAccess='\0') + 509 at tuplesort.c:657
frame #5: 0x00010f2e871d
postgres`initialize_phase(aggstate=0x7fb152817828, newphase=0) + 477 at
nodeAgg.c:456
frame #6: 0x00010f2e73f0
postgres`ExecInitAgg(node=0x7fb1528062e8, estate=0x7fb152817440,
eflags=16) + 2656 at nodeAgg.c:2223
frame #7: 0x00010f2d18e1
postgres`ExecInitNode(node=0x7fb1528062e8, estate=0x7fb152817440,
eflags=16) + 865 at execProcnode.c:296
frame #8: 0x00010f301231
postgres`ExecInitSort(node=0x7fb152806400, estate=0x7fb152817440,
eflags=16) + 225 at nodeSort.c:202
frame #9: 0x00010f2d18a9
postgres`ExecInitNode(node=0x7fb152806400, estate=0x7fb152817440,
eflags=16) + 809 at execProcnode.c:286
frame #10: 0x00010f2ccf20
postgres`InitPlan(queryDesc=0x7fb152803c40, eflags=16) + 1520 at
execMain.c:957
frame #11: 0x00010f2cc81f
postgres`standard_ExecutorStart(queryDesc=0x7fb152803c40, eflags=16) +
591 at execMain.c:237
frame #12: 0x00010f2cc5be
postgres`ExecutorStart(queryDesc=0x7fb152803c40, eflags=0) + 62 at
execMain.c:139
frame #13: 0x00010f48b112
postgres`PortalStart(portal=0x7fb151836c40, params=0x,
eflags=0, snapshot=0x) + 722 at pquery.c:533
frame #14: 0x00010f4871c1
postgres`exec_simple_query(query_string="select unhashable_col,
unsortable_col,\n   grouping(unhashable_col, unsortable_col),\n
count(*), sum(v)\n  from gstest4 group by grouping sets
((unhashable_col),(unsortable_col))\n order by 3, 5;") + 945 at
postgres.c:1065
frame #15: 0x00010f486525 postgres`PostgresMain(argc=1,
argv=0x7fb151801f00, dbname="postgres", username="pavan") + 2245 at
postgres.c:4051
frame #16: 0x00010f3ef392
postgres`BackendRun(port=0x7fb151700540) + 674 at postmaster.c:4254
frame #17: 0x00010f3ee64d
postgres`BackendStartup(port=0x7fb151700540) + 365 at postmaster.c:3928
frame #18: 0x00010f3ed705 postgres`ServerLoop + 597 at
postmaster.c:1698
frame #19: 0x00010f3eb066 postgres`PostmasterMain(argc=3,
argv=0x7fb151403740) + 5414 at postmaster.c:1306
frame #20: 0x00010f32bddf postgres`main(argc=3,
argv=0x7fb151403740) + 751 at main.c:228
frame #21: 0x7fff9c0b1255 libdyld.dylib`start + 1
frame #22: 0x7fff9c0b1255 libdyld.dylib`start + 1


-- 
 Pavan Deolasee   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pg95_assertion_fix.patch
Description: Binary data

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

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-09-09 Thread Alvaro Herrera 
Marko Tiikkaja wrote:
> Hi,
> 
> Running one specific test from our application against REL9_5_STABLE
> (current as of today) gives me this:

Just pushed the fix.  Thanks for the report!

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-17 Thread Alvaro Herrera 
Marko Tiikkaja wrote:

> Running one specific test from our application against REL9_5_STABLE
> (current as of today) gives me this:
> 
> #2  0x7effb59595be in ExceptionalCondition (
> conditionName=conditionName@entry=0x7effb5b27a88 "!(CritSectionCount > 0
> || TransactionIdIsCurrentTransactionId(( (!((tup)->t_infomask & 0x0800) &&
> ((tup)->t_infomask & 0x1000) && !((tup)->t_infomask & 0x0080)) ?
> HeapTupleGetUpdateXid(tup) : ( (tup)-"...,
> errorType=errorType@entry=0x7effb599b74b "FailedAssertion",
> fileName=fileName@entry=0x7effb5b2796c "combocid.c",
> lineNumber=lineNumber@entry=132) at assert.c:54
> #3  0x7effb598e19b in HeapTupleHeaderGetCmax (tup=0x7effa85714c8) at
> combocid.c:131

Can you please do
  frame 3
  print tup->t_ctid
in gdb?  That would print the tuple address with which to grep the xlog
sequence.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-16 Thread Alvaro Herrera 
Andres Freund wrote:

> Phew. Alvaro, are you tackling this?

Sure.


Marko Tiikkaja wrote:

> There's a rolled back subtransaction that also did some magic on the rows
> AFAICT.  I can try and spend some time producing a smaller test case over
> the weekend.  No hurry since this missed the today's point release anyway.

Marko, any luck?

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-16 Thread Andres Freund 
On 2016-08-11 11:01:18 +0200, Marko Tiikkaja wrote:
> On 11/08/16 8:48 AM, Michael Paquier wrote:
> > On Thu, Aug 11, 2016 at 8:09 AM, Marko Tiikkaja  wrote:
> > > On 2016-08-11 12:09 AM, Alvaro Herrera wrote:
> > > > 
> > > > BTW this is not a regression, right?  It's been broken all along.  Or am
> > > > I mistaken?
> > > 
> > > You're probably right.  I just hadn't realized I could run our app against
> > > 9.5 with --enable-cassert until last week.
> > 
> > Just wondering... If you revert 1f9534b4 and/or b33e81cb do you still
> > see a problem?
> 
> Yeah, no effect.

Phew. Alvaro, are you tackling this?


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

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-11 Thread Marko Tiikkaja 

On 11/08/16 8:48 AM, Michael Paquier wrote:

On Thu, Aug 11, 2016 at 8:09 AM, Marko Tiikkaja  wrote:

On 2016-08-11 12:09 AM, Alvaro Herrera wrote:


BTW this is not a regression, right?  It's been broken all along.  Or am
I mistaken?


You're probably right.  I just hadn't realized I could run our app against
9.5 with --enable-cassert until last week.


Just wondering... If you revert 1f9534b4 and/or b33e81cb do you still
see a problem?


Yeah, no effect.


.m


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

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-11 Thread Michael Paquier 
On Thu, Aug 11, 2016 at 8:09 AM, Marko Tiikkaja  wrote:
> On 2016-08-11 12:09 AM, Alvaro Herrera wrote:
>>
>> BTW this is not a regression, right?  It's been broken all along.  Or am
>> I mistaken?
>
>
> You're probably right.  I just hadn't realized I could run our app against
> 9.5 with --enable-cassert until last week.

Just wondering... If you revert 1f9534b4 and/or b33e81cb do you still
see a problem?
-- 
Michael


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

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-10 Thread Marko Tiikkaja 

On 2016-08-11 12:09 AM, Alvaro Herrera wrote:

BTW this is not a regression, right?  It's been broken all along.  Or am
I mistaken?


You're probably right.  I just hadn't realized I could run our app 
against 9.5 with --enable-cassert until last week.



.m


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

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-10 Thread Marko Tiikkaja 

On 2016-08-10 11:01 PM, Alvaro Herrera wrote:

Oh, I see ... so there's an update chain, and you're updating a earlier
tuple.  But the later tuple has a multixact and one of the members is
the current transaction.

I wonder how can you lock a tuple that's not the latest, where that
update chain was produced by your own transaction.  I suppose this is
because of plpgsql use of cursors.


There's a rolled back subtransaction that also did some magic on the 
rows AFAICT.  I can try and spend some time producing a smaller test 
case over the weekend.  No hurry since this missed the today's point 
release anyway.



.m


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

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-10 Thread Alvaro Herrera 
BTW this is not a regression, right?  It's been broken all along.  Or am
I mistaken?

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-10 Thread Alvaro Herrera 
Marko Tiikkaja wrote:
> On 2016-08-10 19:28, Alvaro Herrera wrote:
> >Umm.  AFAICS HeapTupleSatisfiesUpdate() only returns SelfUpdated after
> >already calling HeapTupleHeaderGetCmax() (which obviously hasn't caught
> >the same assertion).  Something is odd there ...
> 
> HeapTupleSatisfiesUpdate() returns HeapTupleBeingUpdated in this case.
> HeapTupleSelfUpdated comes from here (line 4749):
> 
> /* if there are updates, follow the update chain */
> if (follow_updates && !HEAP_XMAX_IS_LOCKED_ONLY(infomask))
> {
> HTSU_Result res;
> res = heap_lock_updated_tuple(relation, tuple, _ctid,
>   GetCurrentTransactionId(),
>   mode);
> if (res != HeapTupleMayBeUpdated)
> {
> result = res;
> /* recovery code expects to have buffer lock held */
> LockBuffer(*buffer, BUFFER_LOCK_EXCLUSIVE);
> goto failed;
>  }
>  }

Oh, I see ... so there's an update chain, and you're updating a earlier
tuple.  But the later tuple has a multixact and one of the members is
the current transaction.

I wonder how can you lock a tuple that's not the latest, where that
update chain was produced by your own transaction.  I suppose this is
because of plpgsql use of cursors.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-10 Thread Marko Tiikkaja 

On 2016-08-10 19:28, Alvaro Herrera wrote:

Umm.  AFAICS HeapTupleSatisfiesUpdate() only returns SelfUpdated after
already calling HeapTupleHeaderGetCmax() (which obviously hasn't caught
the same assertion).  Something is odd there ...


HeapTupleSatisfiesUpdate() returns HeapTupleBeingUpdated in this case. 
HeapTupleSelfUpdated comes from here (line 4749):


/* if there are updates, follow the update chain */
if (follow_updates && !HEAP_XMAX_IS_LOCKED_ONLY(infomask))
{
HTSU_Result res;
res = heap_lock_updated_tuple(relation, tuple, _ctid,
  GetCurrentTransactionId(),
  mode);
if (res != HeapTupleMayBeUpdated)
{
result = res;
/* recovery code expects to have buffer lock held */
LockBuffer(*buffer, BUFFER_LOCK_EXCLUSIVE);
goto failed;
 }
 }


Can you share the test case?


Not at this time, sorry.


.m


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

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-10 Thread Alvaro Herrera 
Marko Tiikkaja wrote:
> Hi,
> 
> Running one specific test from our application against REL9_5_STABLE
> (current as of today) gives me this:
> 
> #2  0x7effb59595be in ExceptionalCondition (
> conditionName=conditionName@entry=0x7effb5b27a88 "!(CritSectionCount > 0
> || TransactionIdIsCurrentTransactionId(( (!((tup)->t_infomask & 0x0800) &&
> ((tup)->t_infomask & 0x1000) && !((tup)->t_infomask & 0x0080)) ?
> HeapTupleGetUpdateXid(tup) : ( (tup)-"...,
> errorType=errorType@entry=0x7effb599b74b "FailedAssertion",
> fileName=fileName@entry=0x7effb5b2796c "combocid.c",
> lineNumber=lineNumber@entry=132) at assert.c:54
> #3  0x7effb598e19b in HeapTupleHeaderGetCmax (tup=0x7effa85714c8) at
> combocid.c:131
> #4  0x7effb55fb0c1 in heap_lock_tuple (relation=0x7effb5bf5d90,
> tuple=tuple@entry=0x7fffcee73690, cid=346,
> mode=mode@entry=LockTupleExclusive, wait_policy=LockWaitBlock,
> follow_updates=follow_updates@entry=1 '\001',
> buffer=buffer@entry=0x7fffcee7367c, hufd=hufd@entry=0x7fffcee73680) at
> heapam.c:4813

Umm.  AFAICS HeapTupleSatisfiesUpdate() only returns SelfUpdated after
already calling HeapTupleHeaderGetCmax() (which obviously hasn't caught
the same assertion).  Something is odd there ...

Can you share the test case?

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-10 Thread Tom Lane 
Marko Tiikkaja  writes:
> The failure is a number of levels down a call stack of PL/PgSQL 
> functions, but I can reproduce it at will by calling the function.  I 
> unfortunately can't narrow it down to a smaller test case, but attached 
> is an xlogdump of the session.  The query that finally breaks the 
> elephant's back is a SELECT .. FOR UPDATE from relid=54511.

> Any ideas on how to debug this?

If this test case used to pass, it'd be pretty useful to git bisect
to find where it started to fail.

regards, tom lane


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

[HACKERS] Assertion failure in REL9_5_STABLE

2016-08-10 Thread Marko Tiikkaja 

Hi,

Running one specific test from our application against REL9_5_STABLE 
(current as of today) gives me this:


#2  0x7effb59595be in ExceptionalCondition (
conditionName=conditionName@entry=0x7effb5b27a88 
"!(CritSectionCount > 0 || TransactionIdIsCurrentTransactionId(( 
(!((tup)->t_infomask & 0x0800) && ((tup)->t_infomask & 0x1000) && 
!((tup)->t_infomask & 0x0080)) ? HeapTupleGetUpdateXid(tup) : ( 
(tup)-"..., errorType=errorType@entry=0x7effb599b74b "FailedAssertion", 
fileName=fileName@entry=0x7effb5b2796c "combocid.c", 
lineNumber=lineNumber@entry=132) at assert.c:54
#3  0x7effb598e19b in HeapTupleHeaderGetCmax (tup=0x7effa85714c8) at 
combocid.c:131
#4  0x7effb55fb0c1 in heap_lock_tuple (relation=0x7effb5bf5d90, 
tuple=tuple@entry=0x7fffcee73690, cid=346, 
mode=mode@entry=LockTupleExclusive, wait_policy=LockWaitBlock, 
follow_updates=follow_updates@entry=1 '\001',
buffer=buffer@entry=0x7fffcee7367c, hufd=hufd@entry=0x7fffcee73680) 
at heapam.c:4813
#5  0x7effb5753e82 in ExecLockRows (node=node@entry=0x7effb6cebb00) 
at nodeLockRows.c:179
#6  0x7effb573cbc8 in ExecProcNode (node=node@entry=0x7effb6cebb00) 
at execProcnode.c:516
#7  0x7effb5739432 in ExecutePlan (dest=0x7effb5dd8160 
, direction=, numberTuples=0, 
sendTuples=1 '\001', operation=CMD_SELECT, planstate=0x7effb6cebb00, 
estate=0x7effb6ceb8f8)

at execMain.c:1549
#8  standard_ExecutorRun (queryDesc=0x7effb6ae3b40, direction=out>, count=0) at execMain.c:337
#9  0x7effb57661db in _SPI_pquery (tcount=0, fire_triggers=1 '\001', 
queryDesc=0x7effb6ae3b40) at spi.c:2411


The failure is a number of levels down a call stack of PL/PgSQL 
functions, but I can reproduce it at will by calling the function.  I 
unfortunately can't narrow it down to a smaller test case, but attached 
is an xlogdump of the session.  The query that finally breaks the 
elephant's back is a SELECT .. FOR UPDATE from relid=54511.


Any ideas on how to debug this?


.m
rmgr: Standby len (rec/tot): 24/50, tx:  0, lsn: 
0/2428, prev 0/23000108, desc: RUNNING_XACTS nextXid 8495 
latestCompletedXid 8494 oldestRunningXid 8495
rmgr: Transaction len (rec/tot): 12/38, tx:   8496, lsn: 
0/2460, prev 0/2428, desc: ASSIGNMENT xtop 8495: subxacts: 8496
rmgr: Heaplen (rec/tot):  7/  1042, tx:   8496, lsn: 
0/2488, prev 0/2460, desc: LOCK off 10: xid 8496 LOCK_ONLY EXCL_LOCK 
KEYS_UPDATED , blkref #0: rel 1663/47473/50461 blk 0 FPW
rmgr: Heaplen (rec/tot):  7/  8246, tx:   8496, lsn: 
0/240004A0, prev 0/2488, desc: LOCK off 48: xid 8496 LOCK_ONLY EXCL_LOCK 
KEYS_UPDATED , blkref #0: rel 1663/47473/51018 blk 81 FPW
rmgr: Heaplen (rec/tot):  7/53, tx:   8496, lsn: 
0/240024F0, prev 0/240004A0, desc: LOCK off 49: xid 8496 LOCK_ONLY EXCL_LOCK 
KEYS_UPDATED , blkref #0: rel 1663/47473/51018 blk 81
rmgr: Sequencelen (rec/tot):158/   204, tx:   8496, lsn: 
0/24002528, prev 0/240024F0, desc: LOG rel 1663/47473/49387, blkref #0: rel 
1663/47473/49387 blk 0
rmgr: Sequencelen (rec/tot):158/   204, tx:  0, lsn: 
0/240025F8, prev 0/24002528, desc: LOG rel 1663/47473/49992, blkref #0: rel 
1663/47473/49992 blk 0
rmgr: Heaplen (rec/tot):  3/  4404, tx:   8497, lsn: 
0/240026C8, prev 0/240025F8, desc: INSERT off 74, blkref #0: rel 
1663/47473/49994 blk 18 FPW
rmgr: Btree   len (rec/tot):  2/  6961, tx:   8497, lsn: 
0/24003800, prev 0/240026C8, desc: INSERT_LEAF off 78, blkref #0: rel 
1663/47473/59412 blk 2 FPW
rmgr: Btree   len (rec/tot):  2/  6933, tx:   8497, lsn: 
0/24005350, prev 0/24003800, desc: INSERT_LEAF off 342, blkref #0: rel 
1663/47473/59414 blk 8 FPW
rmgr: Heaplen (rec/tot):  7/  4910, tx:   8497, lsn: 
0/24006E80, prev 0/24005350, desc: LOCK off 3: xid 8497 LOCK_ONLY KEYSHR_LOCK , 
blkref #0: rel 1663/47473/50005 blk 0 FPW
rmgr: Heaplen (rec/tot):  3/87, tx:   8498, lsn: 
0/240081C8, prev 0/24006E80, desc: INSERT off 75, blkref #0: rel 
1663/47473/49994 blk 18
rmgr: Btree   len (rec/tot):  2/  4273, tx:   8498, lsn: 
0/24008220, prev 0/240081C8, desc: INSERT_LEAF off 76, blkref #0: rel 
1663/47473/59412 blk 13 FPW
rmgr: Btree   len (rec/tot):  2/64, tx:   8498, lsn: 
0/240092D8, prev 0/24008220, desc: INSERT_LEAF off 343, blkref #0: rel 
1663/47473/59414 blk 8
rmgr: Heaplen (rec/tot):  7/53, tx:   8498, lsn: 
0/24009318, prev 0/240092D8, desc: LOCK off 29: xid 8498 LOCK_ONLY KEYSHR_LOCK 
, blkref #0: rel 1663/47473/50005 blk 0
rmgr: Heaplen (rec/tot):  3/  2397, tx:   8496, lsn: 
0/24009350, prev 0/24009318, desc: INSERT off 16, blkref #0: rel 
1663/47473/49389 blk 16 FPW
rmgr: Btree   len (rec/tot):  2/  5773, tx:   8496, lsn: 
0/24009CB0, prev 0/24009350, desc: INSERT_LEAF off 6, blkref #0: rel 
1663/47473/49400 blk 1 FPW
rmgr: Btree   len (rec/tot):