On 2016-08-22 13:16:34 -0400, Robert Haas wrote: > On Sat, Aug 20, 2016 at 3:46 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
