Re: BRIN indexes - TRAP: BadArgument
Jeff Janes <jeff.janes@gmail.com>
From: Jeff Janes <jeff.janes@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
Heikki Linnakangas <hlinnakangas@vmware.com>,
Erik Rijkers <er@xs4all.nl>, Emanuel Calvo <3manuek@esdebian.org>,
Simon Riggs <simon@2ndquadrant.com>,
Nicolas Barbier <nicolas.barbier@gmail.com>,
Claudio Freire <klaussfreire@gmail.com>,
Josh Berkus <josh@agliodbs.com>, Andres Freund <andres@2ndquadrant.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-11-05T17:14:20Z
Lists: pgsql-hackers
Attachments
- brin_crash.pl (application/octet-stream)
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
Commits
-
Refactor per-page logic common to all redo routines to a new function.
- f8f4227976a2 9.5.0 cited
-
Reduce use of heavyweight locking inside hash AM.
- 76837c1507cb 9.3.0 cited
-
Scan the buffer pool just once, not once per fork, during relation drop.
- ece01aae4792 9.2.0 cited
-
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
- 9e2a87b62db8 7.1.1 cited