Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |
Дата | |
Msg-id | CA+TgmoYFPkVHAxVm6Eo+feUJBxY-p3s6RG6TavfXViGYqvuFSg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: [HACKERS] Parallel tuplesort (for parallel B-Tree indexcreation)
Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |
Список | pgsql-hackers |
On Mon, Feb 5, 2018 at 1:03 PM, Peter Geoghegan <pg@bowt.ie> wrote: > It certainly is common. In the case of logtape.c, we almost always > write out some garbage bytes, even with serial sorts. The only > difference here is the *sense* in which they're garbage: they're > uninitialized bytes, which Valgrind cares about, rather than byte from > previous writes that are left behind in the buffer, which Valgrind > does not care about. /me face-palms. So, I guess another option might be to call VALGRIND_MAKE_MEM_DEFINED on the buffer. "We know what we're doing, trust us!" In some ways, that seems better than inserting a suppression, because it only affects the memory in the buffer. Anybody else want to express an opinion here? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: