From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Fix BRIN free space computations |
Date: | 2015-10-27 21:19:21 |
Message-ID: | E1ZrBeL-00056i-3w@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Fix BRIN free space computations
A bug in the original free space computation made it possible to
return a page which wasn't actually able to fit the item. Since the
insertion code isn't prepared to deal with PageAddItem failing, a PANIC
resulted ("failed to add BRIN tuple [to new page]"). Add a macro to
encapsulate the correct computation, and use it in
brin_getinsertbuffer's callers before calling that routine, to raise an
early error.
I became aware of the possiblity of a problem in this area while working
on ccc4c074994d734. There's no archived discussion about it, but it's
easy to reproduce a problem in the unpatched code with something like
CREATE TABLE t (a text);
CREATE INDEX ti ON t USING brin (a) WITH (pages_per_range=1);
for length in `seq 8000 8196`
do
psql -f - <<EOF
TRUNCATE TABLE t;
INSERT INTO t VALUES ('z'), (repeat('a', $length));
EOF
done
Backpatch to 9.5, where BRIN was introduced.
Branch
------
REL9_5_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/cf42abcc653817849398b62c321de654ea2b28cc
Modified Files
--------------
src/backend/access/brin/brin_pageops.c | 63 ++++++++++++++++++++++----------
1 file changed, 43 insertions(+), 20 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-10-27 22:03:48 | pgsql: Document BRIN's inclusion opclass framework |
Previous Message | Alvaro Herrera | 2015-10-27 18:07:36 | pgsql: Cleanup commit timestamp module activaction, again |