Then I will post my response. On Mon, Jan 27, 2014 at 8:54 PM, Peter Geoghegan <p...@heroku.com> wrote: > On Mon, Jan 27, 2014 at 8:20 PM, KONDO Mitsumasa > <kondo.mitsum...@lab.ntt.co.jp> wrote: >> At least, only postgres superuser can see pg_stat_statemnet view in old >> version. >> And you should change document at this sentences. > > No, it was precisely the same situation in every way that matters; the > texts and other details were serialized to disk, on the same > filesystem, with the same permissions. The only difference was that > the texts might not be completely current back then, because time can > pass between shutdown/serialization. From a security perspective, > that's obviously 100% equivalent. Now, if you're saying that the > option to not store the texts existed back then and that made a big > difference, I'm completely unconvinced. That is not the security model > that we follow. How could it be? You're asking us to believe that > there is an environment in which statement execution costs and > normalized query strings are more confidential than *all* of the > actual data stored in the database. You're proposing that for some > users the former is top secret, but the latter is somewhat less > confidential, so it matters that root can also read query texts, a > user already naturally entitled to read *all* data in the database. > You have forced me to say what I would have preferred not to: that's > nonsense, pure and simple. > >> IMHO, I have thought your approach is very rough and have some problems. >> Therefore, I thought >> it will be return with feed back by Tom. >> I'm not sure about your patch in detail. > > How did you know it was very rough without reading it? > >> However, I think your patch have >> another >> porblem that is happened in lessor write-back cache enviroment systems >> which are >> like Windows system. It may cause extreme less performance in these systems. >> Did >> you test it? When we use shared_buffers, it does not let you do physical- >> disk-write untill we want to write it. But your patch cannot control it, it >> may >> cause more lessor performance than linux systems. It will be less >> performance >> than removing LWLock. And your patch might works well only at linux system >> or >> having good write-back cache enviroment systems. > > This is completely fatuous. Tom spent a number of days scrutinizing it > in detail. Perhaps you should actually read the patch, or read the > discussion, and then you'll know why he concluded that my approach was > fundamentally sound. If you have a filesystem that can see huge spikes > in latency due to a write() of a relatively tiny query text, you have > many problems, but blocking other queries that need to record > statement execution costs in the shared hashtable actually isn't one > of them.
-- Peter Geoghegan -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers