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 |
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? |