Re: Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure)
| От | Andres Freund |
|---|---|
| Тема | Re: Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure) |
| Дата | |
| Msg-id | 20160822174620.l4n2kpudmimberzf@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | Re: Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure) (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and
prevent information disclosure)
|
| Список | pgsql-hackers |
On 2016-08-22 13:16:34 -0400, Robert Haas wrote: > On Sat, Aug 20, 2016 at 3:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > So to me, it seems like the core of this complaint boils down to "my > > sanitizer doesn't understand the valgrind exclusion patterns that have > > been created for Postgres". We can address that to some extent by trying > > to reduce the number of valgrind exclusions we need, but it's unlikely to > > be practical to get that to zero, and it's not very clear that adding > > runtime cycles is a good tradeoff for it either. So maybe we need to push > > back on the assumption that people should expect their sanitizers to > > produce zero warnings without having made some effort to adapt the > > valgrind rules. I don't think the runtime overhead is likely to be all that high - if you look at valgrind.supp the peformancecritical parts basically are: - pgstat_send - the context switching is going to drown out some zeroing - xlog insertions - making the crc computation more predictable would actually be nice - reorderbuffer serialization - zeroing won't be a material part of the cost The rest is mostly bootstrap or python related. There might be cases where we *don't* unconditionally do the zeroing - e.g. I'm doubtful about the sinval stuff where we currently only conditionally clear - but the stuff in valgrind.supp seems fine. Andres
В списке pgsql-hackers по дате отправления: