Re: BUG #18875: COPY BINARY tsvector FROM file leads to misaligned memory access
От | Tom Lane |
---|---|
Тема | Re: BUG #18875: COPY BINARY tsvector FROM file leads to misaligned memory access |
Дата | |
Msg-id | 1121363.1743623114@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #18875: COPY BINARY tsvector FROM file leads to misaligned memory access (PG Bug reporting form <noreply@postgresql.org>) |
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > The following script, executed against a build with sanitizers enabled: > CREATE TABLE test_tsvector(t text, a tsvector); > COPY test_tsvector FROM '.../src/test/regress/data/tsearch.data'; > COPY BINARY test_tsvector TO '/tmp/t.data'; > COPY BINARY test_tsvector FROM '/tmp/t.data'; > triggers a runtime error: > 2025-04-02 17:23:25.502 UTC [1721608] LOG: statement: COPY BINARY > test_tsvector FROM '/tmp/t.data'; > tsvector.c:90:59: runtime error: member access within misaligned address > 0x52500005a23c for type 'const struct WordEntryIN', which requires 8 byte > alignment Hmm. This is evidently because of the type pun involved: WordEntryCMP is supposed to compare WordEntry structs, but it's turning around and using compareentry which compares WordEntryIN structs. And those are larger/better aligned. Now compareentry doesn't access anything outside the WordEntry part, but it's theoretically possible that the compiler could generate load instructions that depend on the larger alignment. Given the lack of field reports, that's not happening on any platforms where it would matter. But still we ought to clean it up. ISTM this coding is basically backwards: compareentry should be coded to work on WordEntry structs, and then if it's used to compare WordEntry structs that are embedded in WordEntryIN there's no problem. And then we don't need the WordEntryCMP wrapper at all. Will fix, thanks for the report! regards, tom lane
В списке pgsql-bugs по дате отправления: