Re: BRIN indexes - TRAP: BadArgument

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, Emanuel Calvo <3manuek(at)esdebian(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BRIN indexes - TRAP: BadArgument
Date: 2014-11-05 17:14:20
Message-ID: CAMkU=1xu5onOKni1P9OpTy_TTjUvh62J8xG_+UcYuvPizbMBbw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 4, 2014 at 2:28 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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 Content-Type Size
brin_crash.pl application/octet-stream 8.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-11-05 17:32:27 Re: Sequence Access Method WIP
Previous Message Magnus Hagander 2014-11-05 17:00:32 Re: Time to remove dummy autocommit GUC?