Re: Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, Chapman Flack <chap(at)anastigmatix(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure)
Date: 2016-08-22 17:49:47
Message-ID: CA+Tgmoa=YULkuGiZX+Pw0B-XUCK9bMc9+1U=Jv8V2uArgKKdSw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 22, 2016 at 1:46 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> 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.

Naturally you'll be wanting to conclusively demonstrate this with
benchmarks on multiple workloads, platforms, and concurrency levels.
Right? :-)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-08-22 17:52:32 Re: Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure)
Previous Message Andres Freund 2016-08-22 17:47:34 Re: Proposal for CSN based snapshots