aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeIncrementalSort.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-11-01 18:38:42 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2020-11-01 18:38:42 -0500
commit2330f4d3a87ac43b6ecd31bfd698384888ed03cb (patch)
tree866d44888144bb801ca18ae04a023281546e9af3 /src/backend/executor/nodeIncrementalSort.c
parent0041941f5bbe48ff3a05942efc6aa65f4f389efc (diff)
downloadpostgresql-2330f4d3a87ac43b6ecd31bfd698384888ed03cb.tar.gz
postgresql-2330f4d3a87ac43b6ecd31bfd698384888ed03cb.zip
Fix two issues in TOAST decompression.
pglz_maximum_compressed_size() potentially underestimated the amount of compressed data required to produce N bytes of decompressed data; this is a fault in commit 11a078cf8. Separately from that, pglz_decompress() failed to protect itself against corrupt compressed data, particularly off == 0 in a match tag. Commit c60e520f6 turned such a situation into an infinite loop, where before it'd just have resulted in garbage output. The combination of these two bugs seems like it may explain bug #16694 from Tom Vijlbrief, though it's impossible to be quite sure without direct inspection of the failing session. (One needs to assume that the pglz_maximum_compressed_size() bug caused us to fail to fetch the second byte of a match tag, and what happened to be there instead was a zero. The reported infinite loop is hard to explain without off == 0, though.) Aside from fixing the bugs, rewrite associated comments for more clarity. Back-patch to v13 where both these commits landed. Discussion: https://postgr.es/m/16694-f107871e499ec114@postgresql.org
Diffstat (limited to 'src/backend/executor/nodeIncrementalSort.c')
0 files changed, 0 insertions, 0 deletions