diff options
author | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2015-10-27 18:17:55 -0300 |
---|---|---|
committer | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2015-10-27 18:17:55 -0300 |
commit | 21a4e4a4c9fe417e2462b6f90f6b0e49e32ceba6 (patch) | |
tree | 49dae19887e79f3b91c90200a82a3594c26c2f78 /src/backend/utils/adt/jsonb.c | |
parent | 531d21b75ff6b18ea8638c736a05326ebd519f49 (diff) | |
download | postgresql-21a4e4a4c9fe417e2462b6f90f6b0e49e32ceba6.tar.gz postgresql-21a4e4a4c9fe417e2462b6f90f6b0e49e32ceba6.zip |
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.
Diffstat (limited to 'src/backend/utils/adt/jsonb.c')
0 files changed, 0 insertions, 0 deletions