Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit8c8ba6d

Browse files
committed
Add comment on why pulling data from a "name" index column can't crash.
It's been bothering me for several days that pretending that the cstringdata stored in a btree name_ops column is really a "name" Datum could leadto reading past the end of memory. However, given the current memorylayout used for index-only scans in the btree code, a crash is in fact notpossible. Document that so we don't break it. I have not thought of anyother solutions that aren't fairly ugly too, and most of them lose thefunctionality of index-only scans on name columns altogether, so this seemslike the way to go.
1 parentcb6771f commit8c8ba6d

File tree

1 file changed

+10
-0
lines changed

1 file changed

+10
-0
lines changed

‎src/backend/access/nbtree/nbtree.c

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -433,6 +433,16 @@ btrescan(PG_FUNCTION_ARGS)
433433
* not already done in a previous rescan call. To save on palloc
434434
* overhead, both workspaces are allocated as one palloc block; only this
435435
* function and btendscan know that.
436+
*
437+
* NOTE: this data structure also makes it safe to return data from a
438+
* "name" column, even though btree name_ops uses an underlying storage
439+
* datatype of cstring. The risk there is that "name" is supposed to be
440+
* padded to NAMEDATALEN, but the actual index tuple is probably shorter.
441+
* However, since we only return data out of tuples sitting in the
442+
* currTuples array, a fetch of NAMEDATALEN bytes can at worst pull some
443+
* data out of the markTuples array --- running off the end of memory for
444+
* a SIGSEGV is not possible. Yeah, this is ugly as sin, but it beats
445+
* adding special-case treatment for name_ops elsewhere.
436446
*/
437447
if (scan->xs_want_itup&&so->currTuples==NULL)
438448
{

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp