Re: Confine vacuum skip logic to lazy_scan_skip
От | Thomas Munro |
---|---|
Тема | Re: Confine vacuum skip logic to lazy_scan_skip |
Дата | |
Msg-id | CA+hUKG+g6aXpi2FEHqeLOzE+xYw=OV+-N5jhOEnnV+F0USM9xA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Confine vacuum skip logic to lazy_scan_skip (Melanie Plageman <melanieplageman@gmail.com>) |
Список | pgsql-hackers |
On Sat, Feb 15, 2025 at 7:30 AM Melanie Plageman <melanieplageman@gmail.com> wrote: > Seems valgrind doesn't like this [1]. I'm looking into it. Melanie was able to reproduce this on her local valgrind and eventually we figured out that it's my fault. I put code into read_stream.c that calls wipe_mem(), thinking that that was our standard way of scribbling 0x7f on memory that you shouldn't access again until it's reused. I didn't realise that wipe_mem() also tells valgrind that the memory is now "no access". That makes sense for palloc/pfree because when that range is allocated again it'll clear that. The point is to help people discover that they have a dangling reference to per-buffer data after they advance to the next buffer, which wouldn't work because it's in a circular queue and could be overwritten any time after that. This fixes it, but is not yet my proposed change: @@ -193,9 +193,12 @@ read_stream_get_block(ReadStream *stream, void *per_buffer_data) if (blocknum != InvalidBlockNumber) stream->buffered_blocknum = InvalidBlockNumber; else + { + VALGRIND_MAKE_MEM_UNDEFINED(per_buffer_data, stream->per_buffer_data_size); blocknum = stream->callback(stream, stream->callback_private_data, per_buffer_data); + } Thinking about how to make it more symmetrical...
В списке pgsql-hackers по дате отправления: