Re: BRIN indexes - TRAP: BadArgument - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: BRIN indexes - TRAP: BadArgument
Date
Msg-id CAMkU=1xu5onOKni1P9OpTy_TTjUvh62J8xG_+UcYuvPizbMBbw@mail.gmail.com
Whole thread Raw
In response to Re: BRIN indexes - TRAP: BadArgument  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: BRIN indexes - TRAP: BadArgument  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Tue, Nov 4, 2014 at 2:28 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:

I was clearly too careless about testing the xlog code --- it had
numerous bugs.  This version should be a lot better, but there might be
problems lurking still as I don't think I covered it all.  Let me know
if you see anything wrong.


At line 252 of brin_xlog.c, should the UnlockReleaseBuffer(metabuf) be protected by a BufferIsValid?

XLogReadBufferForRedo says that it might return an invalid buffer under some situations.  Perhaps it is known that those situations can't apply here?


Now I am getting segfaults during normal (i.e. no intentional crashes) operations.  I think I was seeing them sometimes before as well, I just wasn't looking for them.

The attached script invokes the segfault within a few minutes.  A lot of the stuff in the script is probably not necessary, I just didn't spend the time to pair it down to the essentials.  It does not need to be in parallel, I get the crash when invoked with only one job (perl ~/brin_crash.pl 1).

I think this is related to having block ranges which have no tuples in them when they are first summarized.  If I take out the "with t as (delete from foo returning *) insert into foo select * from t", then I don't see the crashes


#0  0x000000000089ed3e in pg_detoast_datum_packed (datum=0x0) at fmgr.c:2270
#1  0x0000000000869be9 in text_le (fcinfo=0x7fff1bf6b9f0) at varlena.c:1661
#2  0x000000000089cfc7 in FunctionCall2Coll (flinfo=0x297e640, collation=100, arg1=0, arg2=43488216) at fmgr.c:1324
#3  0x00000000004678f8 in minmaxConsistent (fcinfo=0x7fff1bf6be40) at brin_minmax.c:213
#4  0x000000000089d0c9 in FunctionCall3Coll (flinfo=0x297b830, collation=100, arg1=43509512, arg2=43510296, arg3=43495856) at fmgr.c:1349
#5  0x0000000000462484 in bringetbitmap (fcinfo=0x7fff1bf6c310) at brin.c:469
#6  0x000000000089cfc7 in FunctionCall2Coll (flinfo=0x28f2440, collation=0, arg1=43495712, arg2=43497376) at fmgr.c:1324
#7  0x00000000004b3fc9 in index_getbitmap (scan=0x297b120, bitmap=0x297b7a0) at indexam.c:651
#8  0x000000000062ece0 in MultiExecBitmapIndexScan (node=0x297af30) at nodeBitmapIndexscan.c:89
#9  0x0000000000619783 in MultiExecProcNode (node=0x297af30) at execProcnode.c:550
#10 0x000000000062dea2 in BitmapHeapNext (node=0x2974750) at nodeBitmapHeapscan.c:104

Cheers,

Jeff
Attachment

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Time to remove dummy autocommit GUC?
Next
From: Heikki Linnakangas
Date:
Subject: Re: Sequence Access Method WIP